EN JA
IPF(5)
IPF(5) FreeBSD File Formats Manual 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 prot = 2049 to any with frags keep fags

規則のツリーの構築

規則の 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/ipf 実行例のディレクトリ。

関連項目

ipf(8), ipfstat(8), ippool.conf(5), ippool(8)