日本語 man コマンド類 (ja-man-1.1j_5) と日本語 man ドキュメント (ja-man-doc-5.4 (5.4-RELEASE 用) など) をインストールすると、以下のような man コマンド閲覧、キーワード検索が コンソールからできるようになります。
4.11-RELEASE-K, 5.4-RELEASE-K, 5.5-RELEASE-K, 6.0-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K, 12.1-RELEASE-K は、 プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K から 12.3-RELEASE-K, 13.0-RELEASE-K から 13.2-RELEASE-K は、全翻訳済み)
13.3-STABLE-K, 15.0-CURRENT-K は現在、作成中で日々更新されています。
Table of Contents
IPF(5) IPF(5)
名称
ipf, ipf.conf - IPFilter ファイアウォール規則ファイル形式
解説
ipf.conf ファイルは、IPFilter のコンポーネントを説明するファイアウォー
ル、パケット認証とパケットのための規則を指定するために使用されます。
ipf.conf ファイルで指定された規則をロードするために、ipf(8) プログラム
が、使用されます。
ファイアウォールとして使用するために、2 つの重要な規則のタイプがありま
す: パケット (ブロック規則) をブロックして落とすもの、とパケットを通り
抜ける (通過規則) 許可するものです。適用する決定に伴うことは、結果に条
件付けるものが適用され、そしてどのようであるかの下で指定する文のコレク
ションです、
ipf.conf で使用することができる最も単純な規則は、次のように表現されま
す:
block in all
pass out all
各規則は、すくなくとも次の 3 つの構成要素を含んでいなければなりません。
* 決定キーワード (pass、block など)
* パケットの方向 (in または out)
* あらゆるアドレス情報に一致するアドレスパターンまたは
"all"
長い行
特に長い規則ラインについて、次のような暗黙のうちに複数にそれらを分割す
ることができます:
pass in on bgeo proto tcp from 1.1.1.1 port > 1000
to 2.2.2.2 port < 5000 flags S keep state
または、明示的に、バックスラッシュ ('\') 文字を使用します:
pass in on bgeo proto tcp from 1.1.1.1 port > 1000 \
to 2.2.2.2 port < 5000 flags S keep state
コメント
ipf.conf ファイルのコメントは、'#' 文字の使用によって示されます。これ
は、次のように、行の最初に置くことができます:
# すべての入力 ICMP パケットを許可する
pass in proto icmp from any to any
または、次のように、好きな部分の終わりに:
pass in proto icmp from any to any # Allow all ICMP packets in
ファイアウォールの規則
このセクションは、ipf.conf ファイルに置かれるファイアウォール規則を構築
する方法について詳細に議論します。
何がよいファイアウォール規則設定を作成するか、または、どのパケットがブ
ロックされるべきか、許可されるべきであるかを説明することは、この文書の
範囲外です。いくつかの提案は、提供されますが、さらに読むことは、何が
in/out を許可するのに安全か安全でないか、完全に理解するはずです。
フィルタ規則キーワード
あらゆるフィルタ規則で見つかった最初の単語は、それと一致するパケットの
結果としての成果は何かを説明しています。パケットヘッダの内容で一致する
ために使用することができる様々なセクションの記述は、下記で追いかけま
す。
それらが何を行うかのほかに、キーワードの完全なリストは、次の通りです:
pass パケットと一致するパス規則は、それが流れる方向に継続するこ
とを許可されるべきであることを ipfilter に示します。
block 規則は、パケットがそれ以上行くことを防ぐことが望ましいと
き、使用されます。"in" 側でブロックされるパケットは、
TCP/IP によって決して見られず、"out" 行くことをブロックさ
れたパケットは、経路上 (wire) で決して見られません。
log IPFilter がログ規則に対してパケットが成功して一致するとき、
ログレコードは、生成され、ipmon(8) に対して読み込むことが
利用可能となります。これらの規則は、パケットが通過するの
を許可されるかどうかに影響しません。それで、パケットが最
初にブロック規則と一致し、次にログ規則と一致するなら、パ
ケットの状態は、ログ規則の後に、それは、まだブロックされ
ます。
count 規則は、設定ファイルにレイアウトされた基準と一致するパケッ
トとバイトをカウントする能力を管理者に提供します。カウン
ト規則は、着信のパスで NAT とフィルタ規則の後に適用されま
す。発信パケットに関して、カウント規則は、NAT の前と、パ
ケットが落される前に適用されます。したがって、カウント規
則は、リンクレイヤの真の指示子として使用することができま
せん。
auth 規則によって、ユーザ空間のプログラムによって処理するために
一致するパケットを、キューに入れます。ユーザ空間のプログ
ラムは、キューに入れられたパケットとパケットで何を行うか
の (block, pass など) 判断を返す別の ioctl システムコール
に関する情報を収集するための ioctl システムコールを行うこ
とに責任があります。キューが満杯になる場合には、パケット
は、結局落とされます。
call 規則に伴う意思決定の一部として取られるより複雑なアクション
のために可能とする、IPFilter に組み込まれた関数へのアクセ
スを提供しています。
decapsulate 規則は、あらゆる他のヘッダ (IP、UDP、AH) を削除し、
次に、新しいパケットとして内側にあるものを処理するように
ipfilter に指示します。UDP でないパケットについて、認識さ
れたプロトコルのカプセル化の解除のみを許可する、規則で指
定されるものは何でも追加して適用される組み込みチェックが
あります。内部のパケットのカプセル化を解除した後に、内部
のパケットに適用されるあらゆるフィルタリングの結果も、別
のパケットに適用されます。
フィルタ規則が適用されるデフォルトの方法は、最後の一致規則が意思
決定を行なうものとして使用されることです。それで、たとえ、パケッ
トと一致する最初の規則が pass でも、ブロックである後の一致の規則
があり、それ以上、規則がパケットと一致しないなら、それは、ブロッ
クされます。
ネットワークインタフェースの照合
2 つ以上のネットワークインタフェースがあるたシステムにおいて、それらの
各々のための異なるフィルタ規則を指定することができることが必要です。ま
ず第一に、これは、異なるネットワークが各ネットワークインタフェースに
よってパケットを送信するからですが、また、ホスト、役割とパケットが、ど
のネットワークインタフェースであるかを識別することができる必要があるセ
キュリティポリシの結果のためです。
ネットワークインタフェースの存在が動的なところで、システムを適合するた
めに、規則がロードされるとき、システムに存在する、フィルタ規則で指定さ
れたネットワークインタフェースに必要ではありません。これは、取り込まれ
ている暗黙のエラー、とキーボード誤りで最も単純な予期しない振る舞いを導
くかもしれません、例えば、hme0 の代わりに hem0 または hme3 の代わりに
hme2 をタイプすること。
Solaris 10 Update 4 以前の Solaris システムにおいて、ループバックインタ
フェース (lo0) のパケットをフィルタすることができないので、それを指定す
るフィルタ規則は、パケットの対応するフローに影響を及ぼしません。これを
有効にする方法についての Solaris 特定の情報ついては、下記を参照してくだ
さい。
フィルタ規則のネットワークインタフェースを含むいくつかの例は、次の通り
です:
block in on bge0 all
pass out on bge0 all
アドレスの照合 (基本)
最初にフィルタリング規則のための一致する最も基礎的な部分は、IP アドレス
と TCP/UDP ポート番号を指定することです。発信元アドレス情報は、フィルタ
規則の "from" 情報によって照合され、宛先アドレス情報は、フィルタ規則の
"to" 情報と照合されます。
IP アドレスのために使用される典型的な形式は、IP アドレス (またはネット
ワーク) に '/' とビットのネットマスクのサイズを表わす数が続く、CIDR 記
法です。この記法は、IPv4 と IPv6 の両方で一致するアドレスを指定のために
使用されます。'/' とビットマスクのサイズが一致する文字列から除外される
なら、指定されたアドレスがホストアドレスで、適用されるネットマスクがす
べて 1 であるべきであると仮定されます。
このいくつかの例は、次の通りです:
pass in from 10.1.0.0/24 to any
block out from any to 10.1.1.1
標準サブネットマスクによって定義することができる境界がない、アドレスの
範囲を指定することは可能ではありません。
アドレスの代わりの名前 (Names instead of addresses)
DNS または /etc/hosts のいずれかによって解決された、またはネット
ワーク名、/etc/networks によって解決されたホスト名は、フィルタ規
則で実際のアドレスの代わりに使用されます。警告: ホスト名が 2 つ
以上のアドレスに拡張するなら、*最初のもの* だけが、フィルタ規則
の構築で使用されます。
フィルタ規則をロードする際に、エラーでないなら、長いディレイをも
たらし、ipf(8) が設定ファイルのその部分を処理しているとき、ブ
ロックされる、DNS パケットの送信と受信の場合に、フィルタ規則のた
めの DNS に依存するとき、注意が必要です。
プロトコルの照合
TCP/UDP ポート情報に基づいたパケットと一致するために、パケットがどのプ
ロトコルでなければならないか示すことが、最初に必要です。これは、"proto"
キーワードを使用して行われ、通常 /etc/protocols ファイルを通してプロト
コル番号にマップされるプロトコル番号または名前のいずれかが続きます。
pass in proto tcp from 10.1.0.0/24 to any
block out proto udp from any to 10.1.1.1
pass in proto icmp from any to 192.168.0.0/16
エラーパケットを送り返す
パケットがブロック規則を使用して、まさに廃棄されるとき、パケットを送信
したホストに与えられるフィードバックはありません。これは、良くもあり悪
くもあります。これがそうであるなら、希望の振る舞いであり、否定されるパ
ケットに関するあらゆるフィードバックを送信するのは望ましくありません。
問題点は、単に 1 つのパケットが廃棄されるので、再試行が必要であると仮定
するので、TCP ポート、または UDP に基づいたアプリケーションで接続しよう
とするホストは、しばしば 2 つ以上のパケットを送信します。ログとなる終り
の結果は、再試行のために複製のエントリで散乱されるようになるかもしれま
せん。
この問題に取り組むために、ブロック規則は、2 つの方法で限定することがで
きます。これらの最初は、TCP に特有で、リセットされた (RST) パケットを返
信するために IPFilter に指示します。このパケットは、それが送信したパ
ケットが拒否されて、そのポートのパケットを送信することをこれ以上に試み
るべきでないことをリモートシステムに示します。受信されたものに応じて
TCP RST パケットを返すように IPFilter に伝えることは、次のような
return-rst キーワードで達成されます:
block return-rst in proto tcp from 10.0.0.0/8 to any
TCP RST パケットを返信するとき、IPFilter は、(それらが異なるなら) それ
が実行しているシステムの発信元アドレスではなく、対象とするターゲットの
発信元アドレスがある、新しいパケットを構築しなければなりません。
IP プロトコル群によって操作される他のプロトコルのすべてについて、返信す
るために、受信パケットが落とされたことを示すエラーは、ICMP エラーパケッ
トを返信することを要求します。また、これらを TCP のために使用することが
できますが、送信するホストは、それが TCP RST パケットと同じ方法でハード
エラーとして受信 ICMP エラーを扱いません。ICMP エラーを返すために、次の
ような block キーワードの後に return-icmp を置くことが必要です:
block return-icmp in proto udp from any to 192.168.0.1/24
ICMP エラーパケットを返すために選択されるとき、また、どんなタイプの
ICMP エラーが返されるかを選択することは可能です。下記の文字列の代わりに
数値を指定することによって ICMP 到達不可能なコードの十分な行動をを使用
することができる一方、次だけが return-icmp とともに使用されるべきです。
どの return コードを使用するかは、賛成と反対を判断するとき、行われる選
択です。コードのいくつかを使用することは、ファイアウォールが単なる応答
しないホストではなく使用されていることをより明白にするかもしれません。
filter-prohib (prohibited by filter; フィルタによって禁止される)
受信パケットで与えられる宛先へのパケットを送信すること
は、パケットフィルタのアプリケーションのために禁止されま
す。
net-prohib (prohibited network; 禁止されるネットワーク) 受信パ
ケットで与えられる宛先へのパケットを送信することは、管理
上禁止されます。
host-unk (host unknown; 未知のホスト) 宛先ホストのアドレスは、パ
ケットを受信するシステムによって知られておらず、したがっ
て、到達できません。
host-unr (host unreachable; 到達不可能なホスト) パケットヘッダの
宛先アドレスによって与えられるようなホストに到達すること
ができません。
net-unk (network unreachable; 未知のネットワーク) 宛先ネットワー
クアドレスは、パケットを受信しているシステムによって知ら
れておらず、したがって、到達することができません。
net-unr (network unreachable; 到達不可能なネットワーク) 宛先アド
レスによって与えられるような最終宛先へのパケットを転送す
ることができません。
port-unr (port unreachable; 到達不可能なポート) 与えられた宛先
ポートを使用するアプリケーションがありません、したがっ
て、そのポートに到着することはできません。
proto-unr (protocol unreachable; 到達不可能なプロトコル) パケッ
トで指定された IP プロトコルは、パケットを受信すうために
利用可能ではありません。
UDP パケットのためのポート到達不可能なパケットを 192.168.1.0/24
に返信する方法の例は、次の通りです:
block return-icmp(port-unr) in proto udp from any to 192.168.1.0/24
上記の例において、ICMP パケットを送信するとき、IPFilter は、オリ
ジナルの発信元にパケットを変数するために使用されるネットワークイ
ンタフェースの発信元アドレスがある新しい ICMP パケットを構築しま
す。これは、パケットをブロックする中間システムがあることを明らか
にすることができます。それがローカルホストにあるかどうかにかかわ
らず、発信元アドレスがオリジナルの宛先であるところで、ICMP パ
ケットを返信する IPFilter を得るために、return-icmp-as-dest は、
次のように使用されます:
block return-icmp-as-dest(port-unr) in proto udp \
from any to 192.168.1.0/24
TCP/UDP ポートの照合
どのプロトコルが一致しているかを指定して、パケットが規則と一致するため
にどのポート番号がなければならないかを示すことは可能です。アドレスとは
異なって使用されているポート番号のために、そのため異なる方法でそれらで
一致することは可能です。IPFilter によって、利用者は、次の論理演算を使用
することができます:
< x ポート番号が x 以上であか、または y 以下であるなら、真です。
<= x パケットのポート番号が x 以下であるなら、真です。
> x パケットのポート番号が x より大きいなら、真です。
>= x パケットのポート番号が x 以上であるなら、真です。
= x パケットのポート番号が x と等しいなら、真です。
!= x パケットのポート番号が x と等しくないなら、真です。
さらに、ポートの範囲を指定する多くの方法があります:
x <> y ポート番号が y 未満で、y より大きいなら、真です。
x >< y ポート番号が x より大きく、y 未満であるなら、真です。
x:y ポート番号が x 以上であり、y 以下であるなら、真です。
このいくつかの例は、次の通りです:
block in proto tcp from any port >= 1024 to any port < 1024
pass in proto tcp from 10.1.0.0/24 to any port = 22
block out proto udp from any to 10.1.1.1 port = 135
pass in proto udp from 1.1.1.1 port = 123 to 10.1.1.1 port = 123
pass in proto tcp from 127.0.0.0/8 to any port = 6000:6009
フィルタ規則のあらゆる特定の発信元または宛先の情報にも言及する望みがな
いなら、すべてのアドレスが規則と一致すると見なされることを示すために単
語 "all" を使用することができます。
IPv4 または IPv6
フィルタ規則があらゆるアドレスなしで構築されるなら、IPFilter は、それと
IPv4 と IPv6 パケットの両方に一致することを試みます。規則の次のリスト
で、IPFilter が期待するネットワークのプロトコルに由来することができるも
のから指定されているアドレスがないので、それぞれいずれか一方のネット
ワークプロトコルに適用することができます。
pass in proto udp from any to any port = 53
block in proto tcp from any port < 1024 to any
明示的に特定の規則がある特別のネットワークアドレスファミリを一致するた
めに、ファミリは、規則に追加されなければなりません。IPv4 について、ファ
ミリ inet を追加する必要があり、IPv6 について、ファミリ inet6 を追加す
る必要があります。したがって、次の規則は、すべてのパケット (IPv4 と
IPv6 の両方) をブロックします。
block in all
しかし、次の例では、すべての IPv4 パケットをブロックし、IPv6 パケットで
のみ許可します:
block in family inet all
pass in family inet6 all
ポート 53 への IPv4 または IPv6 パケットのいずれかを許可するところで、
例から継続し続けるために、ポート 53 への IPv6 パケットのみブロックを許
可する必要があることを変更するために、プロトコルファミリ修飾子に追加す
ることが可能です。
pass in family inet6 proto udp from any to any port = 53
最初の一致対最後の一致
最後に一致した規則からデフォルトの振る舞いを変更するために、最初に一致
した規則の結果を決定し、単語 "quick" は、規則に挿入されます。
拡張されたパケットの照合
平板なアドレスの使用を越える
多くのホストとネットワークまたは様々なホストに対して個別的なフィルタを
単に試みて動作するファイアウォールにおいて、それが、アドレスのプールを
定義するより容易な管理タスクとなることができ、各アドレスのための規則が
あるのではなく、そのアドレスプールを参照するフィルタ規則があります。
アドレスプールを使用することができることに加えて、規則のアドレスフィー
ルドから/アドレスフィールドに (複数の) インタフェース名を使用することは
可能です。アドレスセクションで使用されている名前が規則の "on" または
"via" フィールドで言及されたインタフェース名のいずれかに一致することが
できるなら、それは、拡張された効果のために続くキーワードの 1 つととも使
用することができます:
broadcast このフィルタ規則でパケットと一致させるためにネットワークイン
タフェースの主要なブロードキャストアドレスを使用します。
pass in on fxp0 proto udp from any to fxp0/broadcast port = 123
peer このフィルタ規則でパケットと一致させるためにポイントツーポイントの
ネットワークインタフェースの通信相手 (ピア) アドレスを使用しま
す。このオプションは、典型的に SLIP と PPP のようなリンクプロト
コルで意味のある使用のみがあります。例えば、この規則は、それらが
ファイアウォールの終わりでリンクに割り当てられたアドレスに行くこ
とになっているなら、受信される ppp0 のリモートの通信相手 (ピア)
からの ICMP パケットを許可します。
pass in on ppp0 proto icmp from ppp0/peer to ppp0/32
netmasked このフィルタ規則とパケットを一致させるためのネットワークイン
タフェースの主要なネットワークアドレスを、そのネットマスクで使用
します。ネットワークインタフェースに 192.168.1.1 の IP アドレス
があり、そのネットマスクが 255.255.255.0 (/24) であったなら、イ
ンタフェース名の後の単語 "netmasked" を使用することは、
192.168.1.0/24 と一致するあらゆるアドレスに一致します。bge0 に、
この IP アドレスとネットマスクがあると仮定するうなら、続く 2 つ
の規則は、両方とも、同じ結果を生成する役目をします:
pass in on bge0 proto icmp from any to 192.168.1.0/24
pass in on bge0 proto icmp from any to bge0/netmasked
network 正確な一致のためにアドレスを構築するネットワークインタフェース
の主要なネットワークアドレスを、そのネットマスクを使用します。
ネットワークインタフェースに 192.168.1.1 のアドレスがあり、その
ネットマスクが 255.255.255.0 であるなら、このオプションの使用す
ることは、単に 192.168.1.0 へのパケットに一致します。
pass in on bge0 proto icmp from any to bge0/network
アドレスを得るためのネットワークインタフェースの名前を使用する別の方法
は、() で名前を包むことです。上記の方法で、IPFilter は、与えられた名が
ホスト名またはネットワークインタフェース名であるかどうか決定するため
に、使用中のインタフェース名を調べます。() の使用で、たとえ、それが、規
則 ias が関連付けられるネットワークインタフェースのリストに現われなくて
も、名前がネットワークインタフェース名として扱われるべきであることを
IPFilter に伝えることは可能です。
pass in proto icmp from any to (bge0)/32
アドレスプールを使用する
allow または deny 特有のアドレスのいずれかである、複数の規則をリストア
ウトするのではなく、単一のオブジェクトを作成すし、アドレスプールを呼び
出し、フィルタ規則の、それらのアドレスと参照をすべて含むことができま
す。それらのプールとそれらをロードするための設定ファイルを書く方法につ
いての文書については、ippool.conf(5) と ippool(8) を参照してください。
ippool.conf(5) で定義することができる 2 つのタイプのアドレスプールがあ
ります: ツリーとハッシュテーブルです。ippool.conf(5) で定義されたツリー
を参照するためには、次の構文を使用します:
pass in from pool/trusted to any
pool.conf(5) に既に定義されており、ippool(8) でロードされたものとよく調
和する限り、名前または数値のいずれかを '/' の後ろに使用することができま
す。存在しないプールを参照するうフィルタ規則をロードすることは、エラー
の結果となります。
ハッシュテーブルがツリーの代わりにアドレスを格納するために
ippool.conf(5) 使用されているなら、単語プールをハッシュに置き換えます:
pass in from any to hash/webservers
各々で異なる操作特性があるので、プールがハッシュよりよく動作する、その
逆も、いくつかの状況があります。
TCP フラグの照合
TCP ヘッダは、パケットが接続要求、接続終了、データなどであるかどうか決
定するために使用される、フラグのフィールドを含んでいます。ポート番号と
連動するフラグで一致することによって、IPFilter によって、接続が作成でき
る方法を制限することは可能です。TCP フラグの迅速な要約は、下記にありま
す。各々は、3 つまたは 4 つの文字の pneumonic (肺) が続く、IPFilter 規
則で使用される文字でリストされます。
S SYN - ホストが接続をセットアップすとき、このビットが設定されます。開
始プログラムは、典型的に SYN ビットがあるパケットを送信し、応答
システムは、 ACK と SYN を返信します。
A ACK - 送信側がが別のホストからのパケットの受信を肯定応答したいとき、
このビットがが設定されます。
P PUSH - 送信ホストが、まだ、肯定応答されるいくつかのデータがあり、応答
が要求されるとき、このビットがが設定されます。
F FIN - ダウンした接続をクローズするために開始された接続の終りのとき、
このビットがが設定されます。
U URG - パケットが緊急のデータを含むことを示すために、このビットがが設
定されます。
R RST - 受信されたが、あらゆるオープンされたポートでターゲットでない、
別のものへの応答であるパケットでのみ、このビットがが設定されま
す。
C CWN
E ECN
TCP フラグと一致するとき、設定したいフラグを単にリストすることは正常で
す。デフォルトで、それが比較されるフラグの設定は、"FSRPAU" です。"flags
S" と記述される規則は、"flags S/FSRPAU" があるように、ipfstat(8) によっ
て表示されます。これは、正常です。最後の 2 つのフラグ、"C" と "E" は、
オプションで - それらは、終了ホストによって使用されるかどうか分からな
い、データの受け付けでも接続の制御でもないことに何の関係もありません。
"flags S/FSRPAUCE" でそれらをマスクすることは、成功した接続を行うリモー
トホストのための問題を引き起こします。
pass in quick proto tcp from any to any port = 22 flags S/SAFR
pass out quick proto tcp from any port = 22 to any flags SA
それだけで、TCP フラグに基づいくフィルタリングは、より多くの作業になり
ますが、ステートフル (stateful) なフィルタリング (以下を参照) と組み合
わすとき、状況は、変わります。
ICMP ヘッダ情報上での照合
TCP と UDP は、単なる IP ヘッダを越えてフィルタリングすることが可能なた
だ一つのプロトコルではありません、ICMP パケットで拡張された照合が、さら
に利用可能です。有効な ICMP タイプのリストは、IPv4 と IPv6 によって異な
ります。
実例として、特定のターゲットに対して動作する ping コマンドを可能にする
ことは、次のように、2 つの異なるタイプの ICMP パケットを許可することを
要求します:
pass in proto icmp from any to webserver icmp-type echo
pass out proto icmp from webserver to any icmp-type echorep
ICMP ヘッダには、次のフィルタリングのための興味深い 2 つのフィールドが
あります: ICMP タイプとコード。フィルタ規則は、タイプとコードの両方のた
めの名前または数値のいずれかを受け付けることができます。ICMP タイプのた
めにサポートされた名前のリストは、下記にリストされますが、ICMP 到達不可
能エラーだけに指定されたコードがあります (上記参照)。
IPv4 パケットとの照合のために利用可能な ICMP タイプのリストは、次の通り
です:
echo (echo request), echorep (echo reply), inforeq (information
request), inforep (information reply), maskreq (mask request), maskrep
(mask reply), paramprob (parameter problem), redir (redirect), routerad
(router advertisement), routersol (router solicit), squence (source
quence), timest (timestamp), timestreq (timestamp reply), timex (time
exceeded), unreach (unreachable).
IPv6 パケットとの照合のために利用可能な ICMP タイプのリストは、次の通り
です:
echo (echo request), echorep (echo reply), fqdnquery (FQDN query),
fqdnreply (FQDN reply), inforeq (information request), inforep
(information reply), listendone (MLD listener done), listendqry (MLD
listener query), listendrep (MLD listener reply), neighadvert
(neighbour advert), neighborsol (neighbour solicit), paramprob
(parameter problem), redir (redirect), renumber (router renumbering),
routerad (router advertisement), routersol (router solicit), timex
(time exceeded), toobig (packet too big), unreach (unreachable, whoreq
(WRU request), whorep (WRU reply).
ステートフル (状態を把握する) パケットのフィルタリング
ステートフルなパケットのフィルタリングは、IPFilter が、それが見られる 1
つ以上のパケットからのいくつかの情報を思い出し、それがネットワークから
受信する将来のパケットに、それを適用することができるところです。
これが各トランスポート層プロトコルために意味するものは、異なります。TCP
について、それは、IPFilter が接続を行うための試みのまさに最初のパケット
を見るなら、それらと一致するあらゆる明示的な規則の必要がない他のすべて
の続くパケットを許可するのに十分な情報があることを意味します。IPFilter
は、どのパケットが一致しなければならないか決定するために TCP ポート番
号、TCP フラグ、ウィンドウサイズとシーケンス番号を使用します。UDP につ
いて、UDP ポート番号だけが利用可能です。ICMP について、既に見られる要
求/問い合わせに一致するパケットを応答するかを決定するために ICMP id
フィールドと ICMP タイプを組み合わせことができます。他のすべてのプロト
コルについて、IP アドレスとプロトコル番号でのみ一致することは、受信され
たパケットが既に通過されたものと結合するかどうか判断するために利用可能
です。
これが生じる違いは、2 または 4 から 1 まで規則の数の縮小です。例えば、
これらの 4 つの規則は、次の通りです:
pass in on bge0 proto tcp from any to any port = 22
pass out on bge1 proto tcp from any to any port = 22
pass in on bge1 proto tcp from any port = 22 to any
pass out on bge0 proto tcp from any port = 22 to any
この単一の規則で置き換えることができます:
pass in on bge0 proto tcp from any to any port = 22 flags S keep state
UDP と ICMP のための同様の規則は、次の通りとなるかもしれません:
pass in on bge0 proto udp from any to any port = 53 keep state
pass in on bge0 proto icmp all icmp-type echo keep state
TCP でステートフルなフィルタリングを使用するとき、新しい接続の表示であ
る、状態がパケットが見られるときのみ作成されることを保証する規則に
"flags S" を追加することが最も良いことです。IPFilter は、ステートフルな
フィルタリングを行う TCP 接続の最中でパケットからいくつかの情報を集める
ことができますが、どの TCP 受け付ける有効なウィンドウを変更する、接続の
開始でのみ送信されるいくつかのオプションがあります。中央の接続でピック
アップ TCP 状態を試みる最後の結果は、接続の一部であるいくつかの後のパ
ケットが、落とされるか、またはブロックされ、問題を引き起こして、既知の
状態情報と一致しません。TCP パケットが IP アドレスとポート番号と一致す
るが、認識されたウィンドウに適合しないなら、自動的に許可されず、"out of
window" (oow) として IPFitler の内部でフラグが付けられます。この属性で
一致する方法については、下記の "余分なパケット属性" を参照してくださ
い。
いったん、TCP 接続が確立している状態に到達すると、デフォルトのタイムア
ウトは、ステートテーブルから削除される前に、それが 5 日間アイドルになる
ことを許可します。他の TCP 接続状態のためのタイムアウトは、240 秒から
30 秒まで変化します。UDP と ICMP の両方の状態のエントリは、順方向でパ
ケットを見るとき、設定するタイムアウトが逆方向のためによりもはるかに大
きいところで、非対称のタイムアウトがあります。UDP について、デフォルト
のタイムアウトは、ICMP 60 と 6 秒に対して、120 と 12 秒です。これは、進
行中の接続より問い合わせの応答のためにより多い、これらのプロトコルの使
用の現れです。他のすべてのプロトコルについて、タイムアウトは、両方向で
60 秒です。
ステートフル (状態を把握する) フィルタリングオプション
ステートフルなフィルタリングで、次のオプションを使用することができます:
limit この規則が制限の後に与えられた数に作成することができる、状態テー
ブルエントリの数を制限します。指定された制限がある規則は、たとえ
追加のエントリを作成することによって、テーブルがほかのグローバル
な制限より多くのエントリがあっても、多くの状態テーブルエントリが
常に許可されます。
pass ... keep state(limit 100)
age パケットがそれを通り抜けるのを見るとき、状態エントリのためにタイム
アウトを設定します。さらに、前方のパスよりも異なっている値にファ
イアウォールを通って戻る返答パケットのためにタイムアウトを設定す
ることは可能です。返答の後に設定される短いタイムアウトを許可する
ことが、見られ、状態は、もはや要求されません。
pass in quick proto icmp all icmp-type echo \
keep state (age 3)
pass in quick proto udp from any \
to any port = 53 keep state (age 30/1)
strict TCP と共に使用されるときのみ、影響があります。ファイアウォールを
通されることを許可されるすべてのパケットがシーケンシャルとなるこ
とを強制します: パケットの順序が乱れた配信は、許可されません。こ
れは、いくつかの接続のために顕著な減速を引き起し、他のものは、通
しません。注意して使用してください。
pass in proto tcp ... keep state(strict)
noicmperr 含まれたオリジナルのパケットの内容を使用して、このフラグで作
成された状態テーブルエントリと一致することができる ICMP エラーの
パケットを防ぎます。
pass ... keep state(noicmperr)
sync この件で、他のマシンの状態テーブルをシンク (sync) する責任がある
ユーザランドのデーモンに情報を提供する必要があることを IPFilter
に示します。
pass ... keep state(sync)
nolog 状態テーブルエントリの生成または削除のためにあらゆるログレコード
を生成しません。
pass ... keep state(nolog)
icmp-head 状態テーブルエントリと一致する ICMP エラーパケットを単に防ぐ
のではなく、通常のファイアウォール規則として基づく ICMP エラーパ
ケットをフィルタ in または out することができ処理される ACL を許
可します。icmp-head オプションは、ちょうどヘッドで使用するよう
に、存在するフィルタ規則のグループ番号または名前を要求します。
pass in quick proto tcp ... keep state(icmp-head 101)
block in proto icmp from 10.0.0.0/8 to any group 101
max-srcs 定義される状態エントリを作成することができる区別できるホストの
数を許可します。
pass ... keep state(max-srcs 100)
pass ... keep state(limit 1000, max-srcs 100)
max-per-src max-srcs が状態テーブルエントリの生成を引き起こす個別のホス
トの数を制限する一方、それぞれそれらのホストの 1 つは、グローバ
ルな最大に到達するまで、新しいエントリで状態テーブルを満たすテー
ブルです。このオプションによって、アドレス毎の状態テーブルエント
リの数を制限することができます。
pass ... keep state(max-srcs 100, max-per-src 1)
pass ... keep state(limit 100, max-srcs 100, max-per-src 1)
これらの 2 つの規則が同一に見えかもしれない一方、それらが両方と
も規則から 100 まで作成されたホストと状態テーブルエントリの数を
結局制限するという点において、わずかな違いがあります: 最初は、状
態テーブルが他の規則から満たされるなら、行わないのに対して、2 番
目は、作成される 100 までの状態テーブルエントリを常に許可しま
す。
さらに、ホスト毎の制限がサブネット毎またはネットワーク毎の制限に
なることを有効にするホスト毎の制限の後にネットマスクのサイズを指
定することは可能です。
pass ... keep state(max-srcs 100, max-per-src 1/24)
アドレスまたは規則の他の機能によって暗黙の IP プロトコルがないな
ら、IPFilter は、ネットマスクが IPv4 と IPv6 の両方のためにすべ
て 1 のネットマスクではないことを仮定します。
接続の束縛
ファイアウォールを通過するあらゆる接続について、各パケットは、2 度見ら
れます: 一度は、入るとき、一度は、出るときです。したがって、接続には、
パケットの 4 つの流れがあります:
forward 着信パケット
forward 発信パケット
reverse 着信パケット
reverse 発信パケット
IPFilter によって、パケットの流れの中ですべての 4 つのポイントで使用さ
れるネットワークインタフェースを定義することができます。着信するパケッ
トに一致する規則について、out-via は、パケットが出て行くインタフェース
を指定するために使用されます。発信するパケットに一致する規則について、
in-via は、着信するパケットと一致するために使用されます。いずれの場合に
も、構文は、次に一般化します:
pass ... in on forward-in,reverse-in \
out-via forward-out,reverse-out ...
pass ... out on forward-out,reverse-out \
in-via forward-in,reverse-in ...
ssh 接続によって使用される 4 つのネットワークインタフェースのすべてをく
ぎ付けに (pin down) する例は、次のように見えるかもしれません:
pass in on bge0,bge1 out-via bge1,bge0 proto tcp \
from any to any port = 22 flags S keep state
パケットのフラグメントでの動作
フラグメント化されたパケットは、データが多くの他のパケットに渡って分割
される間に、層 3 と 4 のヘッダ情報をすべて含んでいる 1 つのパケットの結
果となります。
フラグメント化されたパケットでアクセス制御を強制するために、2 つのアプ
ローチのうちの 1 つが取られるかもしれません。最初は、データのフラグメン
トの (オリジナルのパケットの本体を作り上げたもの) すべてを通して許可
し、それが見られるとき、"最初の" フラグメントのヘッダ情報と一致すること
を当てにすることです。最初でない本体のフラグメントの受信は、受信ホスト
が、完全にパケットを再構築し、すべてのフラグメントを廃棄することができ
ない結果となります。次の 3 つの規則は、その場合にも UDP と、それらが、
ポート 2049 のために予定されたものが完了することを単に許可することを除
いて、受信されたすべてのフラグメント化されたパケットを拒否します。
block in all with frags
pass in proto udp from any to any with frag-body
pass in proto udp from any to any port = 2049 with frags
利用可能な別のメカニズムは、"フラグメント状態" を追跡することです。これ
は、層 3 と層 4 ヘッダ情報のすべてを含んでいるフラグメントとなる到着す
るパケットの最初のフラグメントを当てにします。他のどれよりも前にそのフ
ラグメントの受信で、他のフラグメントが、すべてのフラグメントの本体のパ
ケットを明白に許可する必要なしに、許可されることになっているかを決定す
ることは可能です。これがどのように行われたかの例は、次の通りです:
pass in proto udp from any port = 2049 to any with frags keep frags
規則のツリーの構築
規則の 1 つの長いリストとしてフィルタ規則を書くことは、規則の処理に関し
て能率的でなく、理解するのが難しくなります。フィルタ規則を簡単に構築す
るために、それらをグループにを置くことは可能です。規則は、グループのメ
ンバとび新しいグループの先頭の両方を指定できます。
フィルタグループを使用することは、少なくとも 2 つの規則を要求します: 1
つは、グループの 1 つになること、1 つは、一致するパケットをグループに送
信することです。パケットがグループの先頭であるフィルタ規則に一致する
が、そのグループの規則のどれとも一致しないなら、パケットは、先頭の規則
と一致したと見なされます。
グループのメンバである規則は、それらがどのグループにあるか定義する名前
または数のいずれかが続く単語 group を含んでいます。グループのための分岐
点または開始点を形成する規則は、グループ名または数のいずれかに続けて、
単語 head を使用しなければなりません。規則が、グループを定義するという
点においてロードされるが、先頭と一致するものがないなら、それらは、効果
的に孤児にされた規則となります。特定の共通のポリシを実装するサブルーチ
ンのように使用されるグループを可能にして、同じグループを指す 2 つ以上の
先頭の規則をあることは可能です。
フィルタグループの共通の使用は、使用中のインタフェースがある各方向のた
めのフィルタ "main line" に存在する先頭の規則を定義することです。例え
ば、次の通りです:
block in quick on bge0 all head 100
block out quick on bge0 all head 101
block in quick on fxp0 all head internal-in
block out quick on fxp0 all head internal-out
pass in quick proto icmp all icmp-type echo group 100
規則の上記の組で、定義された 4 つのグループがありますが、それらの 1 つ
だけには、メンバ規則があります。上記のルールセットを通して許可されるパ
ケットだけは、bge0 で受信される ICMP エコーパケットとなります。
規則は、グループを時別にすることを許可して、グループのメンバと新しいグ
ループの先頭の両方を指定することができます。
block in quick on bge0 all head 100
block in quick proto tcp all head 1006 group 100
フィルタ規則のグループの別の使用は、それらの特別のすべてのルールセット
のうちの順序付けに関して、心配する必要なしに、動的に追加される規則のた
めの場所を提供することです。例えば、この単純なルールセットを使用してい
たなら、次の通りです:
block in quick all with bad
block in proto tcp from any to any port = smtp head spammers
pass in quick proto tcp from any to any port = smtp flags S keep state
そして、スパムを配信する 10.1.1.1 から電子メールのサーバに多くの接続を
得ていました、上記のものを補足する次の規則をロードすることができました:
block in quick from 10.1.1.1 to any group spammers
カプセル化の解除
また、規則グループは、カプセル化の解除の規則のための異なるが重要な役割
を形成します。次の単純な規則で、IPFilter が、その層 4 ペイロードとして
AH ヘッダがある IP パケットを受信するなら、IPFilter は、パケットの視界
を内部的に調節し、次に、新しい転送ヘッダとして AH ヘッダの向こうのデー
タを使用して、グループ 1001 にジャンプします。
decapsulate in proto ah all head 1001
トンネリングで使用されるように解釈されるか、またはそうでなければ、IP プ
ロトコルをカプセル化の解除について、IPFilter は、あらゆる支援ない内部
で、それに何があるかを決定することができます。いくつかのトンネリングの
プロトコルは、転送機構として UDP を使用します。この場合に、どのプロトコ
ルが内部の UDP かに関して IPFilter に指示することが必要です。
decapsulate l5-as(ip) in proto udp from any \
to any port = 1520 head 1001
現在、IPFilter は、UDP ヘッダの直後に IPv4 と IPv6 ヘッダがあるもののみ
をサポートしています。
パケットがカプセル化の解除の規則と一致するが、指定されたグループ内であ
る規則のいずれかと一致することに失敗するなら、パケットのカプセル化の解
除と IPFilter の内部の視界がカプセル化の解除の規則より前に何かを返えす
後に、パケットの処理は、次の規則を継続します。
ipf(8) が受け付ける、終わりでグループ先頭でないカプセル化の解除の規則を
構築することは可能ですが、そのような規則は、起こっているものすべての結
果となりません。
ポリシに基づいた経路制御
それらがしばしば位置するファイアウォールで、ともに接続された異なるネッ
トワークの境界と、異なるプロパティがある複数の接続の境界で、経路表が
カーネルに指示するものと異なる方角にパケットを流すことは、しばしば望ま
しいことです。発信元と宛先アドレスの両方、または偶数のポート番号に基づ
いた経路を変更するために、これらの決定をしばしば拡張することができま
す。
この種の設定をサポートするために、IPFilter によって、次の中継点 (hop)
の宛先を、フィルタ規則で指定することができます。次の中継点は、出力のた
めに使用するインタフェース名で与えられます。このための構文は、
interface:ip.address です。次の中継点として与えられるアドレスは、ネット
ワークが直接インタフェースに接続されることが期待されます。
pass in on bge0 to bge1:1.1.1.1 proto tcp \
from 1.1.2.3 to any port = 80 flags S keep state
この機能がステートフルなフィルタリングと組み合わされるとき、今、パケッ
トのその逆の流れが何のためであるかに気が付くので、パケットを両方向に送
信するために使用されるネットワークインタフェースに影響を及ぼすことが可
能となります。
pass in on bge0 to bge1:1.1.1.1 reply-to hme1:2.1.1.2 \
proto tcp from 1.1.2.3 to any port = 80 flags S keep state
経路表のアクションが完全に受け付け可能であるが、それらが通過する IP パ
ケットの TTL を変更しないことによってファイアウォールの存在をマスクした
いなら、次ような "fastroute" アクションを行うために IPFilter に指示する
ことができます。
pass in on bge0 fastroute proto icmp all
これは、それが無限のパケットのループに導く可能性があるので、注意して使
用されるべきです。さらに、ポリシベースの経路制御は、IP ヘッダの TTL 値
を変更しません。
規則のこのタイプの変化は、作成されているオリジナルのパケットの複写をサ
ポートし、異なるネットワークに送信します。これは、トラフィックと他の目
的をモニタするために役に立つことができます。
pass in on bge0 to bge1:1.1.1.1 reply-to hme1:2.1.1.2 \
dup-to fxp0:10.0.0.1 proto tcp from 1.1.2.3 \
to any port = 80 flags S keep state
IPv4 オプションの照合
IPv4 のための設計によって、ヘッダは、最大 64 バイトの長さまで許可されま
すが、しかしながら、ほとんどのトラフィックは、長さ 20 バイトである基本
的なヘッダのみを使用します。IP オプションを格納するために、他の 44 バイ
トを使用することができます。これらのオプションは、一般的に今日のイン
ターネットの適切な相互作用と関数に対して必要ではありません。ほとんどの
人々にとって、それは、あらゆるオプションの設定があるすべてのパケットを
ブロックし、落とすために十分です。次の規則で、これを達成することができ
ます:
block in quick all with ipopts
この規則は、通常、すべての着信パケットがブロックできるように、設定の先
頭の方に置かれます。
特定の IP オプションのタイプで許可したかったなら、構文は、わずかに変わ
ります:
pass in quick proto igmp all with opt rtralrt
次は、ほとんどの人々が遭遇する IP オプションとそれらを使用/扱うもののリ
ストです。
lsrr (loose source route; 緩い発信元の経路) パケットの送信側は、宛先へ
の方向を通じて経路となるパッケットが希望するアドレスのリストを含
んでいます。そのようなパケットへの応答が、逆のあどれ琉のリストを
使用すると予想されるので、ハッカは、アドレスなりすましの攻撃で、
このヘッダオプションを非常に効果的に使用することができます。
rr (record route; 経路記録) 送信側は、パケットが通過する各ルータの IP
アドレスを記録するためのバッファ空間を割り付けます。これは、ping
の応答が、パケットがそこに着くまでどの経路であるかを送信側に伝え
て、オリジナルのパケットからのすべてのアドレスのコピーを含んでい
るところで、ほとんどの場合に ping で使用されます。IP ヘッダオプ
ションで実行とセキュリティの問題のために、これは、もはやほとんど
使用されません。
rtralrt (router alert; ルータ警報) このオプションは、パケットが異なって
扱われる必要があるルータへのフラグとして IGMP メッセージでしばし
ば使用されます。それは、知らない送信側から受信されそうもありませ
ん。それは、RSVP プロトコルとマルチキャストのトラフィックがヘ
ビーな使用中である LAN またはそうでなければ制御されたネットワー
クで見つかるかもしれません。
ssrr (strict source route; 厳密な発信元経路) パケットの送信側は、宛先へ
の途中まで経路制御されたパケットを希望するアドレスのリストを含ん
でいます。lsrr オプションによって送信側が、ssrr オプションで、パ
ケットが通過しなければならないノードのいくつかだけを指定すること
ができるところで、すべての次の中継点のルータは、指定されなければ
なりません。
一致することができる IPv4 オプションの完全なリストは、次の通りです:
addext (Address Extention), cipso (Classical IP Security Option), dps
(Dynamic Packet State), e-sec (Extended Security), eip (Extended
Internet Protocol), encode (ENCODE), finn (Experimental Flow Control),
imitd (IMI Traffic Descriptor), lsrr (Loose Source Route), mtup (MTU
Probe - obsolete), mtur (MTU response - obsolete), nop (No Operation),
nsapa (NSAP Address), rr (Record Route), rtralrt (Router Alert), satid
(Stream Identifier), sdb (Selective Directed Broadcast), sec
(Security), ssrr (Strict Source Route), tr (Tracerote), ts (Timestamp),
ump (Upstream Multicast Packet), visa (Experimental Access Control) and
zsu (Experimental Measurement).
CIPSO と IPSO でのセキュリティ
IPFilter は、IPv4 パケットで、パケットの IP オプション部分に埋め込まれ
たセキュリティ属性を使用してフィルタリングをサポートします。これらのオ
プションは、ラベル付けされたセキュリティを使用しているネットワークとシ
ステムでのみ通常使用されます。ラベルが付けられたセキュリティを使用して
おり、ネットワーキングもラベル付けられることを知っていないなら、このセ
クションが関連していることは、まったくありそうにありません。
伝統的な IP (Security Options; セキュリティオプション) (IPSO) で、セ
キュリティレベルでパケットをタグを付けることができます。次のキーワード
が認識され、一致したビットパターンについて関連する RFC と一致します:
confid (confidential), rserve-1 (1st reserved value), rserve-2 (2nd
reserved value), rserve-3 (3rd reserved value), rserve-4 (4th reserved
value), secret (secret), topsecret (top secret), unclass
(unclassified).
block in quick all with opt sec-class unclass
pass in all with opt sec-class secret
IPv6 拡張ヘッダの照合
ちょうど様々な IPv4 ヘッダオプションでフィルタリングすることが可能なよ
うに、IPv6 ヘッダと転送プロトコルヘッダの間に置かれる IPv6 拡張ヘッダで
フィルタリングすることも可能です。
dstopts (destination options), esp (encrypted, secure, payload), frag
(fragment), hopopts (hop-by-hop options), ipv6 (IPv6 header), mobility
(IP mobility), none, routing。
ログ記録
パケットが IPFilter でログ記録することができる 2 つの方法があります。最
初は、パケットのこれらのタイプをログ記録することを特に記述する規則であ
り、2 番目は、他のキーワードの 1 つへの修飾子です。したがって、両方をロ
グ記録することが可能で、単一の規則があるパケットを allow または deny し
ます。
pass in log quick proto tcp from any to any port = 22
ステートフルなフィルタリングを使用するとき、ログアクションは、パケット
に関して記憶される結果の一部となります。したがって、上記の規則が状態の
維持で修飾されたなら、接続ですべてのパケットが記録されます。単に、状態
の維持で追跡されるすべてのパケットの流れから最初のパケットをログ記録す
るために、最初のパケットをログ記録したいことだけを IPFilter に示すこと
が必要です。
pass in log first quick proto tcp from any to any port = 22 \
flags S keep state
ログ記録が、接続が許可される正確な表現を提供することが要求されるなら、
ログアクションを、オプションの or-block で修飾することができます。これ
によって、管理者は、IPFilter のカーネルの (サイズに上界がある) ログレ
コードでパケットを記録する試みが失敗したなら、IPFilter に指示することが
できます。システムのシャットダウンまたはリブートしないなら、いったんロ
グレコードが、カーネルバッファに書き込まれると、ipmon(8) がそれを読み込
むまで、それは、バッファにあります。
block in log proto tcp from any to any port = smtp
pass in log or-block first quick proto tcp from any \
to any port = 22 flags S keep state
デフォルトで、IPFilter は、ネットワークで受信されるパケットのヘッダ部分
のみログ記録します。また、パケットの本体の 128 バイトまで、本体のキー
ワードでログ記録することができます。ipmon(8) は、16 進数でログインされ
た本体の部分の内容を表示します。
block in log body proto icmp all
ipmon(8) から syslog までのパケットをログ記録するとき、デフォルトで、
ipmon(8) は、パケットがログ記録される、syslog 機能とプライオリティを制
御します。次のような、規則ごとの基準で、これを調整することができます:
block in quick log level err all with bad
pass in log level local1.info proto tcp \
from any to any port = 22 flags S keep state
ipfstat(8) は、どれだけのパケットが成功してログ記録されたか、どれだけの
パケットをログ記録する試みに失敗したかを報告します。
フィルタ規則コメント
テキスト文字列を関連させる要求があるなら、IPFilter 規則がある、管理上の
コメントかそうでないものとなり、これは、フィルタ規則のコメントを与える
ことによって、達成することができます。コメントは、規則を付けてカーネル
にロードされ、規則が ipfstat でリストされるとき、見ることができます。
pass in quick proto tcp from any \
to port = 80 comment "all web server traffic is ok"
pass out quick proto tcp from any port = 80 \
to any comment "all web server traffic is ok"
タグ
規則で正確にパケットを調和させるためにフィルタリングと NAT を有効にする
ために、(着信パケットのための) NAT と (発信パケットのための) フィルタリ
ングでタグを追加することができます。これによって、フィルタは、それが何
であった明白ではないことを意味する方法でパケットを変更した NAT 規則であ
るイベントの、その NAT 規則を正確に結合することができます。
着信のパケットについて、IPFilter は、NAT によって設定されたものでフィル
タ規則で使用されるタグと一致することができます。発信の規則について、そ
れは逆で、フィルタは、タグを設定し、NAT 規則は、それと調和します。
pass in ... match-tag(nat=proxy)
pass out ... set-tag(nat=proxy)
タグの別の使用は、ログ記録でのみ使用される数を供給することです。パケッ
トがこれらの規則と一致するとき、ログのタグは、ipmon(8) によって生成され
たログファイルレコードに持ち越されます。grep のようなツールの正確な使用
で、興味のあるログレコードの抽出は、単純化されます。
block in quick log ... set-tag(log=33)
フィルタ規則の期限切れ
IPFilter によって、規則の終わりに rule-ttl を指定することによって、特定
の期間の後に削除するカーネルに規則を追加されることができます。
ipfstat(8) を使用してカーネルの規則をリストするとき、期限が切れかってい
る規則は、タイムアウトで "rule-ttl" を表示せず、むしろ、見られるもの
は、どれだけの規則を残した ipfilter のチックが生存していなければならな
いかがあるコメントです。
有効期間は、秒単位で指定されます。
pass in on fxp0 proto tcp from any \
to port = 22 flags S keep state rule-ttl 30
内部パケット属性
特殊なネットワークと転送ヘッダフィールドでフィルタリングすることができ
ることに加えて、IPFilter がパケットにアタッチする他の属性でフィルタリン
グすることは可能です。これらの属性は、上記の frags と frag-body で見る
ことができるような、キーワード "with" の後の規則に置かれます。次は、利
用可能な他の属性のリストです:
oow パケットの IP アドレスと TCP ポートは、ステートテーブルの既存のエン
トリと一致しますが、シーケンス番号は、それが受け付けられたウィン
ドウの外側であることを示します。
block return-rst in quick proto tcp from any to any with not oow
bcast これは、それがリンクレイヤのパケットがブロードキャスト (同報通信)
のパケットだったという通知を受信するとき、 IPFilter によって設定
されます。IP アドレスのチェックは、それがブロードキャストの宛先
かどうか判断するために実行されません。
block in quick proto udp all with bcast
mcast これは、それがリンクレイヤのパケットがマルチキャストのパケット
だったという通知を受信するとき、 IPFilter によって設定されます。
IP アドレスのチェックは、それがマルチキャストの宛先かどうか判断
するために実行されません。
pass in quick proto udp from any to any port = dns with mcast
mbcast オペレーティングシステムによって示されるように、リンクレイヤのマ
ルチキャストまたはブロードキャストのパケットのいずれかであるパ
ケットと一致するために使用することができます。
pass in quick proto udp from any to any port = ntp with mbcast
nat NAT テーブルエントリと確実に一致されたパケット。
bad 失敗したパケットの健全性のチェック。これは、層 3/4 ヘッダが適切に形
成されないことを示すかもしれません。
bad-src 逆のパスの検証が有効になるとき、このフラグは、パケットが受信さ
れるインタフェースが受信されたパケットの発信元アドレスにパケット
を送信するために使用されるものと一致しないとき、設定されます。
bad-nat パケットで NAT を行なう試みは、失敗しました。
また、"with" キーワードを使用して一致される各属性の 1 つで存在しないた
めに検索することができません。例えば、よいパケットでのみ許可する
ために、次のようにすることができます:
block in all
pass in all with not bad
IPFilter の調整
また、可能にして、IPFilter の振る舞いを調整するために ipf.conf ファイル
を使用することができます、例えば、それらのサイズと共に設定される NAT/状
態テーブルのためのタイムアウト。調整変数の存在と名前は、IPFilter の 1
つのリリースから次のもので変更するかもしれません。ipf.conf を通して変更
することができる調整変数は、ipf(8) への -T コマンド行オプションを使用し
て、見られ、修正することができるものと同じです。
注: ipf.conf を解析するとき、ipf(8) は、あらゆる規則をロードする前に、
設定を適用します。したがって、利用者の設定が先頭であるなら、これらは、
適用されますが、規則は、設定ファイルのズット下にエラーがあるなら、適用
されません。
下記の値の 1 つに設定するために、構文は、単純です: 設定する調整変数の名
前によって続く、"set" と、次に、それに設定する値。
set state_max 9999;
set state_size 10101;
ipf.conf から調整される IPFilter の内部の現在、利用可能な変数のリスト
は、次の通りです:
active ipf(8) の -s コマンド行スイッチを通して設定します。詳細について
は、ipf(8) を参照してください。
chksrc 設定されるとき、発信元アドレスと bad-src 属性でパケットを一致す
るフィルタのために、逆のパスの検証を有効にします。
control_forwarding カーネルのフォワーディングをオフに設定するとき、
IPFilter が無効にされるか、またはアンロードされるとき。
default_pass デフォルトのポリシ - パケットが、ブロックされるか、または
通過されるかどうか、など - この変数の値によって表示される。それ
は、ビットフィールドで、設定することができるビットは、
<netinet/ip_fil.h> にあります。この値を直接調整することは、推奨
されません。
ftp_debug カーネル内 FTP プロキシのデバッグレベルを設定します。デバッグ
メッセージは、システムコンソールに印刷 (表示) されます。
ftp_forcepasv 設定されたとき、FTP プロキシは、227 応答のための状態/NAT
エントリを作る前に PASV/EPSV コマンドを見なければなりません。
ftp_insecure 設定されたとき、FTP プロキシは、データ接続を作成できる前
に、ログインするユーザのためにウェートしません。
ftp_pasvonly 設定されたとき、プロキシは、PORT または EPRT コマンドのい
ずれかを見るときのために状態/NAT エントリを作成します。
ftp_pasvrdr 有効にされることによって、FTP プロキシは、227 の応答が見ら
れるとき、クライアントとサーバのホストの間のあらゆる接続を許可す
る非常に安全でない NAT/状態エントリを作成します。最高に注意して
使用してください。
ftp_single_xfer 設定されたとき、FTP プロキシは、同時に 1 つのデータ接続
のみ許可します。
hostmap_size スティッキ (sticky) 規則で使用のためにアドレスのマッピング
を格納するために、NAT によって使用される hostmap テーブルのサイ
ズを設定します。
icmp_ack_timeout 応答パケットが既に存在する ICMP 状態のために見られると
き、ICMP NAT/状態のために使用されたデフォルトのタイムアウト。
icmp_minfragmtu 不良 (bad) パケットであると決定する前に、ICMP エラーで
受け付け可能と見なされる最小の MTU を設定します。
icmp_timeout パケットが規則と一致するとき、ICMP NAT/状態のために使用さ
れるデフォルトのタイムアウト。
ip_timeout TCP/UDP/ICMP でない NAT/状態エントリのために使用するデフォル
トのタイムアウト。
ipf_flags
ips_proxy_debug これは、プロシキサポートコードのためにデバッグレベルを
設定します。有効にされたとき、デバッグメッセージは、システムコン
ソールに印刷 (表示) されます。
log_all 設定されたとき、ちょうど最初の 128 バイトではなくすべてのパケッ
トをログ記録するために "log body" の振る舞いを変更します。
log_size バイト単位でカーネル内ログバッファのサイズを設定します。
log_suppress 設定されたとき、IPFilter は、それがログ記録しているパケッ
トが、それが以前にログ記録したものに似ているかどうかチェックし、
そうであるなら、そのパケットのための発生のカウントを増加させま
す。以前にログ記録されたパケットは、ipmon(8) によってまだ読み込
まれてはいけません。
min_ttl これは、下記のパケットが low-ttl 属性でマークされる TTL 値を設
定するために使用されます。
nat_doflush 設定されるなら、それは、NAT コードは、次の機会で NAT テーブ
ルのより積極的なフラッシュを行ないます。いったんフラッシュが行わ
れたならば、値は、0 にリセットされます。
nat_lock これは、ipfs(8) を使用してのみ変更されるべきです。
nat_logging 設定されたとき、NAT は、/dev/ipnat から読み込むことができる
ログレコードを作成します。
nat_maxbucket 各 NAT ハッシュのバケット (bucket) に存在することを許可さ
れるエントリの最大数。これは、性能を縮小して、単一のバケットのエ
ントリでハッシュテーブルにロードしようとする攻撃者を防ぎます。
nat_rules_size マップ規則を格納するハッシュテーブルのサイズ。
nat_table_max NAT テーブルに許可されたエントリの最大数。
nat_table_size NAT のために使用されるハッシュテーブルのサイズ。
nat_table_wm_high NAT テーブルの十分なパーセンテージがこのマークを超過
するとき、より積極的なフラッシュは、有効になります。
nat_table_wm_low これは、NAT テーブルの積極的なフラッシュがそれ自体をオ
フに切り替えるパーセンテージを設定します。
rdr_rules_size rdr 規則を格納するハッシュテーブルのサイズ。
state_lock これは、ipfs(8) を使用してのみ変更されるべきです。
state_logging 設定されたとき、ステートフルのフィルタリングは、
/dev/ipstate から読み込むことができるログレコードを作成します。
state_max 状態テーブルに許可されたエントリの最大数。
state_maxbucket 各状態ハッシュバケットに存在することを許可されたエント
リの最大数。これは、性能を縮小して、単一のバケットのエントリで
ハッシュテーブルにロードしようとする攻撃者を防ぎます。
state_size ステートフルなフィルタリングのために使用されたハッシュテーブ
ルのサイズ。
state_wm_freq これは、いったん状態テーブルが十分なパーセンテージで
state_wm_high を越えると、攻撃的なフラッシュがどれくらい頻繁で実
行するべきであるかを制御します。
state_wm_high 状態テーブルの十分なパーセンテージが、このマークを超過す
るとき、より積極的なフラッシュは、有効になります。
state_wm_low これは、状態テーブルの積極的なフラッシュがそれ自体をオフに
切り替えるパーセンテージを設定します。
tcp_close_wait TCP の状態エントリが、FIN_WAIT_2 状態に到達するとき、使
用されるタイムアウト。
tcp_closed TCP の状態エントリがいずれかの RST パケットが見られる後、削
除される準備ができているとき、使用されるタイムアウト。
tcp_half_closed TCP の状態エントリが CLOSE_WAIT 状態に到達するとき、使
用されるタイムアウト。
tcp_idle_timeout TCP の状態エントリが ESTABLISHED 状態に到達するとき、
使用されるタイムアウト。
tcp_last_ack TCP NAT/状態エントリが LAST_ACK 状態に到達するとき、使用さ
れるタイムアウト。
tcp_syn_received SYN-ACK パケットが見られた後に、TCP NAT/状態エントリに
適用されるタイムアウト。
tcp_syn_sent SYN パケットが見られたの後に、TCP NAT/状態エントリに適用さ
れるタイムアウト。
tcp_time_wait TCP NAT/状態エントリが TIME_WAIT 状態に到達するとき、使用
されるタイムアウト。
tcp_timeout TCP NAT/状態エントリが半分確立している状態 (1 つの ack は、
SYN-ACK の後に見られます) または 1 つの側が FIN_WAIT_1 のいずれ
かに到達するとき、使用されるタイムアウト。
udp_ack_timeout 応答パケットが既に存在する UDP 状態のために見られると
き、UDP NAT/状態のために使用されるデフォルトのタイムアウト。
udp_timeout パケットが規則と一致するとき、UDP NAT/状態のために使用され
たデフォルトのタイムアウト。
update_ipid 設定されたとき、NAT のパケットの IP id を乱数に変更すること
をオンに切り替えます。
可視の変数のテーブル
調整変数、それらの最小、最大と現在の値のすべてのリストは、次の通りで
す。
名前 最小 最大 現在
active 0 0 0
chksrc 0 1 0
control_forwarding 0 1 0
default_pass 0 MAXUINT 134217730
ftp_debug 0 10 0
ftp_forcepasv 0 1 1
ftp_insecure 0 1 0
ftp_pasvonly 0 1 0
ftp_pasvrdr 0 1 0
ftp_single_xfer 0 1 0
hostmap_size 1 MAXINT 2047
icmp_ack_timeout 1 MAXINT 12
icmp_minfragmtu 0 1 68
icmp_timeout 1 MAXINT 120
ip_timeout 1 MAXINT 120
ipf_flags 0 MAXUINT 0
ips_proxy_debug 0 10 0
log_all 0 1 0
log_size 0 524288 32768
log_suppress 0 1 1
min_ttl 0 1 4
nat_doflush 0 1 0
nat_lock 0 1 0
nat_logging 0 1 1
nat_maxbucket 1 MAXINT 22
nat_rules_size 1 MAXINT 127
nat_table_max 1 MAXINT 30000
nat_table_size 1 MAXINT 2047
nat_table_wm_high 2 100 99
nat_table_wm_low 1 99 90
rdr_rules_size 1 MAXINT 127
state_lock 0 1 0
state_logging 0 1 1
state_max 1 MAXINT 4013
state_maxbucket 1 MAXINT 26
state_size 1 MAXINT 5737
state_wm_freq 2 999999 20
state_wm_high 2 100 99
state_wm_low 1 99 90
tcp_close_wait 1 MAXINT 480
tcp_closed 1 MAXINT 60
tcp_half_closed 1 MAXINT 14400
tcp_idle_timeout 1 MAXINT 864000
tcp_last_ack 1 MAXINT 60
tcp_syn_received 1 MAXINT 480
tcp_syn_sent 1 MAXINT 480
tcp_time_wait 1 MAXINT 480
tcp_timeout 1 MAXINT 480
udp_ack_timeout 1 MAXINT 24
udp_timeout 1 MAXINT 240
update_ipid 0 1 0
内部関数への呼び出し
IPFilter は、グループを見つける規則のリストを通して歩くのではなくグルー
プにジャンプする単一の規則のために許可する規則から呼び出すことができる
1 組の関数を提供します。規則のそれ自体のグループ毎に、複数のネットワー
クを確保しているなら、この機能は、よりよいろフィルタリングの性能を提供
することを支援します。
ジャンプする規則グループを見つける検索は、発信元アドレスまたは宛先アド
レスの両方ではない、いずれかで行われます。
この下記の例において、デフォルトによってすべてのパケットをブロックしま
すが、次に、グループ 1010 からの発信元アドレスで検索を行ないます。
ipf.conf セクションの 2 つの規則は、それらのグループの単独のメンバで
す。1.1.1.1 からである着信パケットについて、次の 3 つの規則を通過 (経
験) します: グループ 1020 のための (1) 規則をブロックする、(2) 規則を呼
び出す、(3) 規則をパスする。また、3.3.2.2 からであるパケットについて、
次の 3 つの規則を通過 (経験) します: グループ 1030 のための (1) 規則を
ブロックする、(2) 規則を呼び出す、(3) 規則をパスする。3.1.1.1 からのパ
ケットが到着するなら、最初の規則とだけ一致するものだけ残して、グループ
1010 のエントリのいずれかと一致しないものとしてブロックされます。
from ipf.conf
-------------
block in all
call now srcgrpmap/1010 in all
pass in proto tcp from any to any port = 80 group 1020
pass in proto icmp all icmp-type echo group 1030
from ippool.conf
----------------
group-map in role=ipf number=1010
{ 1.1.1.1 group = 1020, 3.3.0.0/16 group = 1030; };
IPFilter 照合表現
規則をフィルタリングするために追加された実験的な機能は、することです、
状態/NAT テーブルエントリをフラッシュしてリストする様々なコマンドで利用
可能である一致する同じ表現を使用することです。そのような表現の使用は、
通常の IP ヘッダの一致を使用することからフィルタ規則を排除します。
pass in exp { "tcp.sport 23 or tcp.sport 50" } keep state
BPF でのフィルタ規則
カーネルに BPF を組み込むプラットフォームにおいて、フィルタ規則の BPF
表現を許可するために IPFilter を構築することができます。これは、パケッ
トの任意のデータにある一致するパケットを考慮に入れます。BPF 表現の使用
は、IPFilter によって行われる一致する別のプロトコルヘッダのすべてを置き
換えます。
pass in bpf-v4 { "tcp and (src port 23 or src port 50)" } \
keep state
これらの規則は、カーネルにロードされた BPF 指示にフィルタ表現をコンパイ
ルする行為が、正確にオリジナルテキストのフィルタを再構成するすることを
難しくすることができるので、書き込み専用となる傾向があります。最後の結
果は、ipf.conf() が簡単に読み込むことができる一方、ipfstat からの出力の
理解がそうでないかもしれないということです。
変数
この設定ファイルは、IPFilter で使用されるすべての他のもののように、テキ
ストの全体にわたって変数置換の使用をサポートします。
nif="ppp0";
pass in on $nif from any to any
は、次のようになります
pass in on ppp0 from any to any
変数は、パーザが foo のための割り当てに到達するとき、$bar が存在する限
り、'foo="$bar baz";' のように、再帰的に使用することができます。
シェル環境から使用される変数を定義する方法に関する説明については、
ipf(8) を参照してください。
関連ファイル
/dev/ipf /etc/ipf.conf
/usr/share/examples/ipfilter 実行例のディレクトリ。
関連項目
ipf(8), ipfstat(8), ippool.conf(5), ippool(8)
IPF(5)