日本語 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
PF.CONF(5) FreeBSD ファイルフォーマットマニュアル PF.CONF(5)
名称
pf.conf -- パケットフィルタ設定ファイル
解説
pf(4) パケットフィルタは、pf.conf で指定された規則か定義に従って、パケッ
トを変更するか、落とすか、または通過させます。
文の順序
pf.conf には、7 つのタイプの文があります:
Macros
ユーザ定義変数は、設定ファイルを簡素化して、後で定義されて使用され
ます。マクロは、それらが pf.conf で参照される前に定義されなければな
りません。
Tables
テーブルは、多くの発信元 (始点) または宛先 (終点) アドレスで規則の
性能と柔軟性を増強するためのメカニズムを提供します。
Options
オプションは、パケットフィルタエンジンの振る舞いを調整します。
Traffic Normalization (例えば、scrub)
トラフィックの正常化は、インターネットプロトコルと実装における矛盾
に対して内部のマシンを保護します。
Queueing
キューは、規則ベースの帯域幅制御を提供します。
Translation (様々な形式の NAT)
変換規則は、アドレスがどのように他のアドレスにマップされるか、また
はリダイレクト (出力先変更) されるかを指定します。
Packet Filtering
パケットフィルタリングは、パケットの規則ベースの遮断 (ブロック) ま
たは通過 (パス) を提供します。
macros と tables を除いて、文のタイプは、基本的なパケットフィルタエンジン
の操作に適合するように、上記に示したような順序で pf.conf に分類されて、現
れるべきです。デフォルトで、pfctl(8) は、この順序で実行します (下記の set
require-order 参照)。
ハッシュマーク (`#') を使用して現在の行の終りまでファイル中のどこでもコメ
ントを置くことができます。
include キーワードで追加の設定ファイルを含むことができます、例えば:
include "/etc/pf/sub.filter.conf"
マクロ
マクロは、後でコンテキストで拡張されるように定義することができます。マク
ロ名は、文字から始まらなければならず、文字、数字、下線を含むことができま
す。マクロ名は、予約語であってはいけません (例えば、pass, in, out)。マク
ロは、引用文の中で展開されません。
例えば、
ext_if = "kue0"
all_ifs = "{" $ext_if lo0 "}"
pass out on $ext_if from any to any
pass in on $ext_if proto tcp from any to any port 25
テーブル
テーブルは、アドレスとネットワークの収集を保持することができる指定された
構造体です。(規則の拡張によって明示的か自動的に作成される) IP アドレスだ
けにおいて異なる多くの規則より、プロセッサの用法とメモリ消費に関して、
テーブルがはるかに効率的であるただ一つの規則を作って、pf(4) のテーブルに
対する検索は、比較的速いです。
テーブルは、フィルタ規則、scrub 規則または nat や rdr のような変換規則
(様々な規則タイプに関する詳細に関して以下を参照) の発信元 (始点) または宛
先 (終点) として使用することができます。また、テーブルは、nat と rdr 規則
のリダイレクトアドレスのためと、フィルタ規則の経路制御 (ルーティング) オ
プションで使用することができますが、round-robin (ラウンドロビン) プールの
ためだけです。
テーブルは、次の pfctl(8) メカニズムのいずれでも定義することができます。
マクロと同様に、予約語は、テーブル名として使用することはできません。
manually 永続的なテーブルは、ルールセット (ruleset) がロードされる前か後
に、pfctl(8) の add または replace オプションで、手動で作成する
ことができます。
pf.conf テーブル定義は、直接このファイルに置くことができ、他の規則が
ロードされるのと同時に不可分にロードすることができます。pf.conf
中のテーブル定義は、table 文を使用して、永続的でないテーブルを
定義するために特に役に立ちます。それを初期化するためにアドレス
のリストなしで定義された前もって存在するテーブルの内容は、
pf.conf がロードされるとき、変更されません。空のリストで初期化
されたテーブル { } は、ロード時にクリアされます。
テーブルは、次の属性で定義されます:
persist persist (持続) フラグによって、どんな規則もそれを参照しないとき
でさえ、カーネルは、強制的にテーブルを保存します。それにを参照す
る最後の規則がフラッシュされるとき、フラグが設定されないなら、
カーネルは、自動的にテーブルを削除します。
const const (不変) フラグは、それがいったん作成されるとユーザがテーブ
ルの内容を変更することを防ぎます。そのフラグがなければ、pfctl(8)
は、securelevel(7) = 2 で実行するときでさえ、いつでもテーブルに
アドレスを追加するか、または削除するために使用することができま
す。
counters
counters フラグは、pfctl(8) で表示することができる、アドレス毎の
パケットとバイトカウンタを有効にします。この機能は、大きなテーブ
ルのための重要なメモリのオーバヘッドとなることに注意してくださ
い。
例えば、
table <private> const { 10/8, 172.16/12, 192.168/16 }
table <badhosts> persist
block on fxp0 from { <private>, <badhosts> } to any
RFC 1918 プライベートネットワークブロックを保持するために private と呼ば
れるテーブルと初めに空である badhosts と呼ばれるテーブルを作成します。
フィルタ規則は、どちらのテーブルにもリストされたアドレスから来るすべての
トラフィックをブロックするるために設定されます。private テーブルは、内容
を変更することができません、そして、アクティブフィルタ規則がそれに参照を
しないときでさえ、badhosts テーブルは、存在します。アドレスは、次を使用す
ることによって、これらのホストからのトラフィックをブロックすることができ
るように、後で badhosts テーブルに追加できます。
# pfctl -t badhosts -Tadd 204.92.77.111
また、テーブルは、次の構文を使用して、1 つ以上の外部のファイルで指定され
たアドレスリストで初期化することができます:
table <spam> persist file "/etc/spammers" file "/etc/openrelays"
block on fxp0 from <spam> to any
ファイル /etc/spammers と /etc/openrelays は、1 行に 1 つの IP アドレスを
リストします。# で始まるどんな行も、コメントとして扱われて、無視されま
す。さらに、IP アドレスによって指定されることよって、ホストは、また、それ
らのホスト名によって指定されます。リゾルバがテーブルにホスト名を追加する
ために呼び出されるとき、すべての結果の IPv4 と IPv6 アドレスは、テーブル
に置かれます。また、有効なインタフェース名、有効なインタフェースグループ
または自己キーワードを指定することによって、テーブルに IP アドレスを入れ
ることができます、その場合、(複数の) インタフェースに割り当てられたすべて
のアドレスがテーブルに追加されます。
オプション
pf(4) は、set コマンドを使用して様々な状況のために調整されます。
set timeout
interval 期限が切れた状態と断片を消去する間隔。
frag 組み立てられていない断片の期限が切れる前の秒数。
src.track 最後の状態の期限が切れた後にソースの追跡エントリを持ち続
ける時間の長さ。
パケットがステートフル (stateful) 接続に適合するとき、接続が存続す
る秒は、接続状態に対応する proto.modifier の内容に更新されます。こ
の状態に適合する各パケットは、TTL (生存時間) をリセットします。これ
らの値を調整することは、有効なアイドル接続を落とすというリスクで
ファイアウォールの性能は、向上します。
tcp.first
最初のパケットの後の状態。
tcp.opening
かってパケットを送信した宛先 (終点) ホストの前の状態。
tcp.established
完全に確立された状態。
tcp.closing
最初の FIN が送信された後の状態。
tcp.finwait
FIN が交換されて、接続が閉じられた後の状態。いくつかのホスト
(とりわけ Solaris 上の web サーバ) は、かって接続を閉じた後に
TCP パケットを送信します。tcp.finwait (と、ことによると
tcp.closing) を増加させることは、そのようなパケットのブロック
を防ぐことができます。
tcp.closed
1 つの終点が RST を送信した後の状態。
ICMP と UDP は、TCP と同様のやり方で取り扱われますが、はるかに限ら
れた状態のセットで取り扱われます:
udp.first
最初のパケットの後の状態。
udp.single
発信元 (始点) ホストが 1 つ以上のパケットを送信しますが、宛先
(終点) ホストが決して返送しない場合の状態。
udp.multiple
両方のホストがパケットを送信した場合の状態。
icmp.first
最初のパケットの後の状態。
icmp.error
ICMP パケットに応答して ICMP エラーが復帰した後の状態。
他のプロトコルは、UDP と同様に取り扱われます:
other.first
other.single
other.multiple
タイムアウト値は、ステート (状態) テーブルエントリの数が大きくなる
のに適応して減少することができます。
adaptive.start
状態エントリの数がこの値を超えるとき、適応できるスケーリング
(拡大縮小) は、始まります。すべてのタイムアウト値は、因数
(adaptive.end - 状態の数) / (adaptive.end - adaptive.start)
で直線的にスケーリング (拡大縮小) されます。
adaptive.end
この状態エントリの数に達するとき、効果的に直ちにすべての状態
エントリを消去してすべてのタイムアウト値は、0 になります。ス
ケール因数を定義するために、この値は、使用され、実際にそれに
到達するべきではありません (下位の状態の制限の設定してくださ
い、下記参照)。
適応するタイムアウトは、状態の制限の 60% と等しい adaptive.start 値
と状態の制限の 120% と等しい adaptive.end 値で、デフォルトで有効に
されます。adaptive.start と adaptive.end の両方を 0 に設定すること
によって、それらを無効にすることができます。
適応するタイムアウト値は、グローバルと各規則のための両方を定義する
ことができます。1 つの規則ベース毎に使用されるとき、値は、規則に
よって作成された状態の数に関連し、そうでなければ、状態の合計数に関
連します。
例えば、
set timeout tcp.first 120
set timeout tcp.established 86400
set timeout { adaptive.start 6000, adaptive.end 12000 }
set limit states 10000
9000 の状態テーブルエントリで、タイムアウト値は、(tcp.first 60,
tcp.established 43200) 50% に調整されます。
set loginterface
与えられたインタフェースまたはインタフェースグループのためのパケッ
トとバイトカウント統計の収集を有効にします。これらの統計は、次を使
用して見ることができます。
# pfctl -s info
この例では、pf(4) は、dc0 と名前が付けられたインタフェースで統計を
収集します:
set loginterface dc0
次を使用して loginterface を無効にすることができます:
set loginterface none
set limit
パケットフィルタによって使用されるメモリプールでの強固な制限を設定
します。メモリプールの説明に関しては、zone(9) を参照してください。
例えば、
set limit states 20000
これは、(no state を指定しない pass 規則によって生成される) 状態
テーブルエントリによって使用されるメモリプール中のエントリの最大数
を 20000 に設定します。次を使用して
set limit frags 20000
(scrub 規則によって生成される) 断片再構築のために使用されるメモリ
プール中のエントリの最大数を 20000 に設定します。次を使用して
set limit src-nodes 2000
sticky-address と src.track オプションによって生成される) トレース
(追跡) ソース IP アドレスのために使用されるメモリプール中のエントリ
の最大数を 20000 に設定します。次を使用して、
set limit tables 1000
set limit table-entries 100000
テーブルによって使用されるメモリプールの制限を設定します。1 番目
は、存在することができるテーブルの数を 1000 に制限します。2 番目
は、テーブルに格納することができるアドレスの全体的な数を 100000 に
制限します。
次のように、単一の行で様々な制限を結合することができます:
set limit { states 20000, frags 20000, src-nodes 2000 }
set ruleset-optimization
none ルールセットオプティマイザを無効にします。
basic 基本的なルールセットの最適化を有効にします。これは、デ
フォルトの振る舞いです。基本的なルールセットの最適化は、
ルールセット評価の性能を向上させるために次の 4 つのことを
行います:
1. 重複する規則を削除します
2. 別の規則の部分集合である規則を削除します
3. 有利なときに、複数の規則をテーブルに結合します
4. 評価性能を改良するために規則に再順序付けします
profile 実際のネットワークトラフィックへの迅速な規則の順序付けを
調整するためにフィードバックプロフィールとして現在ロード
されたルールセットを使用します。
ルールセットオプティマイザが性能を向上させるためにルールセットを変
更することに注意することは重要です。ルールセット変更の副作用は、規
則毎のアカウント統計には、以前と異なった意味があるということです。
請求目的のようなもののために規則毎のアカウントが重要であるなら、
ルールセットオプティマイザを使用するべきではありません、または最適
化バリアとして機能するアカウント規則のすべてにラベルフィールドを追
加するべきです。
また、pf.conf の設定を上書きして、コマンドライン引数として pfctl(8)
に最適化を設定することができます。
set optimization
次のネットワーク環境の 1 つのために状態タイムアウトを最適化します:
normal
正常なネットワーク環境。ほとんどすべてのネットワークで適切で
す。
high-latency
高度なレイテンシ環境 (衛星接続などの)。
satellite
high-latency (高度なレイテンシ) のための別名。
aggressive
接続を積極的に終了します。これは、早く無駄な接続を落とすこと
を犠牲にして、ファイアウォールのメモリ使用量を大幅に減少させ
ることができます。
conservative
非常に保守的な設定。(ビジーネットワークでことによるとはるかに
大きい) より大きいメモリ使用量とわずかに増強されたプロセッサ
使用量を犠牲にして正当な接続を落とすことを避けます。
例えば、
set optimization aggressive
set block-policy
block-policy オプションは、パケット block 動作のためのデフォルトの
振る舞いを設定します:
drop パケットは、静かに落とされます。
return ブロックされた TCP パケットのために TCP RST を返し、ブ
ロックされた UDP パケットのために ICMP UNREACHABLE を返
し、そして、静かに他のすべてのパケットを落とします。
例えば、
set block-policy return
set fail-policy
fail-policy オプションは、パケットを渡すべきですが、そうすることが
できなかった、規則の振る舞いを設定します。nat または規則への経路
は、ターゲットのリストとして空のテーブルを使用するとき、または規則
が、状態またはソースノードを作成することに失敗するなら、これは、起
こるかもしれません。次の block のアクションが可能です:
drop 着信してくるパケットは、静かに落とされます。
return 着信してくるパケットは、落とされて、TCP RST は、TCP パ
ケットのために返され、ICMP UNREACHABLE は、UDP パケットの
ために返され、応答は、他のパケットのために送信されませ
ん。
例えば:
set fail-policy return
set state-policy
state-policy オプションは、状態のためのデフォルトの振る舞いを設定し
ます:
if-bound 状態は、インタフェースにバインドされます。
floating 状態は、どんなインタフェースのパケットにも適合すること
ができます (デフォルト)。
例えば:
set state-defaults no-sync
set state-defaults
state-defaults オプションは、明白な keep state なしで規則から作成さ
れた状態のための状態オプションを設定します。例えば:
set state-defaults pflow, no-sync
set hostid
32 ビットの hostid は、このファイアウォールのステートテーブルエント
リと pfsync(4) フェイルオーバクラスタの他のファイアウォールを識別し
ます。デフォルトで、hostid は、擬似ランダム値に設定されますが、例え
ば、より容易にステートテーブルエントリのソースを識別するために、手
動でそれを設定することは望ましいかもしれません。
set hostid 1
hostid は、10 進数または 16 進数のいずれかで指定されます。
set require-order
デフォルトでは、pfctl(8) は、次のルールセットで文のタイプの順序で実
行します: options, normalization, queueing, translation,
filtering。このオプションを no に設定すれば、この実行を無効にしま
す。順序通りでないルールセットへの重要で明白でない意味があるかもし
れません。実行順序を無効にする前に、熟考してください。
set fingerprints
与えられたファイル名から知られているオペレーティングシステムの指紋
をロードします。デフォルトで、知られているオペレーティングシステム
の指紋は、/etc の pf.os(5) から自動的にロードされますが、このオプ
ションで無効にすることができます。このオプションを設定することは、
現在アクティブなルールセットによって参照された指紋が、新しいルール
セットのロードが終了するまで、一貫性のないところで、短な期間にその
ままとなるかもしれません。
例えば:
set fingerprints "/etc/pf.os.devel"
set skip on <ifspec>
パケットがフィルタされるべきでないインタフェースをリストします。ま
るで pf が無効にされるかのように渡されたインタフェースで内と外に渡
されるパケットです、すなわち、pf は、決してそれらを処理しません。こ
れは、パケットフィルタリングが望まれていなくて、予期されない効果が
あるかもしれないとき、ループバックと他の仮想のインタフェースで役に
立つちます。例えば:
set skip on lo0
set debug
次の 1 にデバッグ level (レベル) を設定します:
none デバッグがメッセージを生成しません。
urgent 重大なエラーの場合だけデバッグメッセージを生成しま
す。
misc 様々なエラーのデバッグメッセージを生成します。
loud 一般的な状態のデバッグメッセージを生成します。
トラフィックの正常化
トラフィック正常化は、受信側でパケットの解釈であいまいさがないような方法
でパケットの内容をクリアするために使用されます。正常化機能は、IP フラグメ
ントを重ね合わせながら送信することによって侵入検出システムを混乱させる攻
撃を防ぐために IP フラグメント再構築します。パケット正常化は、scrub 指令
で呼び出されます。
scrub には、次のオプションがあります:
no-df
適合している IP パケットから dont-fragment ビットをクリアします。い
くつかのオペレーティングシステムは、dont-fragment ビットの設定でフ
ラグメント化されたパケットを生成することが知られています。これは、
NFS で特に当てはまります。scrub は、no-df が指定されないなら、その
ようなフラグメント化された dont-fragment パケットを落とします。
また、残念ながらいくつかのオペレーティングシステムは、0 の IP 識別
フィールドで、それらの dont-fragment パケットを生成します。0 の IP
ID があるパケットで dont-fragment ビットをクリアすると、アップスト
リーム (上流) のルータが後でパケットをフラグメント化するなら、有害
な結果となるかもしれません。random-id 修飾子 (下記参照) を使用する
と、ユニークな IP 識別子を確実にするために no-df 修飾子と組み合わせ
ることが勧められます。
min-ttl <number>
適合している IP パケットのために最小の TTL を強制します。
max-mss <number>
適合している IP パケットのために最大の MSSL を強制します。
set-tos <string> | <number>
一致いている IP パケットのための TOS を強制します。TOS は、
critical, inetcontrol, lowdelay, netcontrol, throughput,
reliability の 1 つとして、または DiffServ Code Points の 1 つとし
て与えられます: ef, af11 ... af43, cs0 ... cs7; または 16 進数また
は 10 進数のいずれかとして。
random-id
多くのホストによって生成された予測できる値を補正するために IP 識別
フィールドをランダムな値に置き換えます。このオプションは、省略可能
なフラグメントの再構築の後にフラグメント化されないパケットだけに適
用されます。
fragment reassemble
scrub 規則を使用して、フラグメントは、正常化によって再構築すること
ができます。この場合、完成したパケットを形成するまで、フラグメント
は、バッファリングされ、完成したパケットだけがフィルタに渡されま
す。利点は、フィルタ規則が完成したパケットだけに対処しなければなら
なくて、フラグメントを無視することができるということです。キャッ
シュフラグメントの欠点は、追加メモリコストです。
reassemble tcp
ステートフル (処理状態を把握する) 正常化 TCP 接続。scrub reassemble
tcp (再構築 tcp) 規則は、指定された (in/out) 指令はありません。
reassemble tcp (再構築 tcp) は、次の正常化を実行します:
ttl 接続のどちら側もそれらの IP TTL を減少させることができま
す。攻撃者は、ファイアウォールに到達して、ファイアウォール
状態に影響して、宛先 (終点) ホストに到達する前に期限が切れ
るように、パケットを送るかもしれません。reassemble tcp
は、接続に見られる最も高い値まですべてのパケットの TTL を
引き上げます。
timestamp modulation
最新の TCP スタックは、あらゆる TCP パケットでタイムスタン
プを送信し、他の終点のタイムスタンプをそれらにエコーしま
す。多くのオペレーティングシステムは、最初にブートされると
き、0 でタイムスタンプを単に始め、何度か 1 秒それを増加し
ます。ホストの動作可能時間は、タイムスタンプを読み込んで、
一定で増加することを推定することができます。また、いくつか
の異なったタイムスタンプを観測することは、NAT デバイスの後
ろのホストを数えるために使用することができます。そして、接
続へのなりすまし TCP パケットは、有効なタイムスタンプを
知っているか、または推測することを必要とします。タイムスタ
ンプは、単に単調に増加して、推測可能な基本時間から導けない
必要があります。reassemble tcp は、scrub をランダムな数で
TCP タイムスタンプを変化させます。
extended PAWS checks
パケットが 32 ビットのシケーンスの空間を折り返すために接続
を試みるより長い間遅れるかもしれないので、長くて太いパイプ
上の TCP で問題があります。そのようなことが起これは、古い
パケットは、新しいパケットと区別できないでしょう、そういう
ものとして受け付けるでしょう。この解決策は、PAWS と呼ばれ
ます: Protection Against Wrapped Sequence (折り返された
シーケンスに対する保護) 番号。各パケットに関するタイムスタ
ンプが後方に行かないことを確実にすることによって、それから
保護します。また、reassemble tcp は、パケットに関するタイ
ムスタンプが RFC で許されているものより進んでいないことを
確実にします。そうすれば、pf(4) は、盲目的な攻撃者も同様
に、タイムスタンプを推測しなければならないので、ホストが適
切にランダマイズされたタイムスタンプを使用するとき、10 か
ら 18 ビットまでに、人為的に TCP シーケンス番号のセキュリ
ティを拡張します。
例えば、
scrub in on $ext_if all fragment reassemble
scrub 規則の前に no オプションを付けることによって、パケットフィルタの
drop quick 動作と同じ方法で、一致するパケットは、scrub されずに残ります
(下記参照)。このメカニズムは、広範囲の scrub 規則から特定のパケットを排除
する必要があるとき、使用されるべきです。
キューイング
現在、ALTQ システムは、GENERIC カーネルもロード可能モジュールとしても利用
可能ではありません。キューイングオプションの一つが呼び出された後の時点で
使用するために、カスタム構築カーネルを使用しなければなりません。関連する
カーネルオプションに関して知るためには、altq(4) を参照してください。
パケットは、帯域幅制御の目的のためのキューに割り当てることができます。
キューを設定するためには、少なくとも 2 つの宣言を必要とし、後のどんなパ
ケットフィルタリング規則は、名前で定義されたキューを参照することができま
す。pf.conf の構成要素のフィルタリングの間に、最後に参照された queue の名
前は、pass 規則からのどんなパケットもキューに入れられるところです、一方、
block 規則の場合は、何か結果として起こる ICMP または TCP RST パケットがど
このキューに入れられるべきであるかを指定しますが。scheduler (スケジュー
ラ) は、どのパケットが遅れるか、落とされるか、または直ちに送出されるか、
を決定するために使用されるアルゴリズムを定義します。現在サポートされてい
る 3 つの scheduler (スケジューラ) があります。
cbq クラスベースのキューイング (Class Based Queueing)。queue は、ツリー
を構築するインタフェースにアタッチします、したがって、各 queue は、
さらなる子供の queue を持つことができます。各キューは、priority (優
先順序) と bandwidth (帯域幅) を割り当てることができます。priority
は、主として送出させるためにかかる時間パケットを制御しますが、一方
bandwidth は、主としてスループットに影響を与えます。cbq は、階層的
に構造化されたクラスによってリンク帯域幅のパーティショニングと共有
の両方を達成します。各クラスは、それ自体の queue (キュー) があり、
bandwidth (帯域幅) の共有が割り当てられます。子供のクラスは、余分な
帯域幅が利用可能である限り、(下記のオプション borrow 参照) 親のクラ
スから帯域幅を借りることができます。
priq 優先順序キューイング (Priority Queueing)。queue は、インタフェース
にフラットにアタッチされ、したがって、queue さらなる子供の queue を
持つことができません。各 queue は、0 から 15 までの範囲で、ユニーク
な priority を割り当てられます。最も高い priority がある queue にお
けるパケットは、最初に処理されます。
hfsc 階層的なフェアサービスカーブ (Hierarchical Fair Service Curve)。
queue は、ツリーを構築するインタフェースにアタッチします、したがっ
て、各 queue は、さらなる子供の queue を持つことができます。各
キューは、priority (優先順序) と bandwidth (帯域幅) を割り当てるこ
とができます。priority は、主として送出させるためにかかる時間パケッ
トを制御しますが、一方 bandwidth は、主としてスループットに影響を与
えます。hfsc は、リンクの共有と保証されたリアルタイムサービスの両方
をサポートします。それは、サービスカーブベースの QoS モデルを使用
し、そのユニーク機能は、delay と bandwidth (帯域幅) 割り付けを分離
する能力です。
キューが活性化されるべきであるインタフェースは、altq on 宣言を使用して宣
言されます。altq on には、次のキーワードがあります:
<interface>
キューは、指定されたインタフェースで有効にされます。
<scheduler>
使用するキュースケジューラを指定します。現在サポートされた値は、ク
ラスベースのキューイングのための cbq と、優先順序キューイングのため
の priq と階層的なフェアサービスカーブスケジューラのための hfsc で
す。
bandwidth <bw>
インタフェースでのすべてのキューのための最大のビットレートは、
bandwidth キーワードを使用して指定できます。絶対値として、または、
インタフェース帯域幅の割合として値を指定することができます。絶対値
を使用するとき、接尾辞 b, Kb, Mb と Gb は、それぞれ、1 秒毎のビッ
ト、キロビット、メガビットとギガビットを表すのために使用されます。
値は、インタフェース帯域幅を超えてはいけません。bandwidth (帯域幅)
が指定されないなら、インタフェース帯域幅は、使用されます (が、いく
つかのインタフェースがそれらの帯域幅を知らないか、またはそれらの帯
域幅レートを適合できることに注意してください)。
qlimit <limit>
パケットの最大数は、キューに保持されます。デフォルトは、50 です。
tbrsize <size>
トークンバケツ調節装置のバイト単位のサイズを調整します。指定されな
いなら、サイズを決定するためにインタフェース帯域幅に基づく発見的手
法が使用されます。
queue <list>
インタフェースで作成するサブキューのリストを定義します。
次の例では、インタフェース dc0 は、クラスベースのキューイングを使用して 4
つの第 2 レベルのキューおける最大 5Mbps でキューを作るべきです。それらの
4 つのキューは、後の例で示されます。
altq on dc0 cbq bandwidth 5Mb queue { std, http, mail, ssh }
インタフェースが altq 指令を使用してキューのためにいったんアクティブにさ
れると、queue 指令のシーケンスが定義されます。queue に関連している名前
は、altq 指令 (例えば、メール) で定義されたキューに適合しなければなりませ
ん、または、親の queue 宣言の priq scheduler を除いて、キューに適合しなけ
ればなりません。次のキーワードを使用することができます:
on <interface>
キューの操作をオンにするインタフェースを指定します。与えられないな
ら、すべての適合するインタフェースを動作させます。
bandwidth <bw>
キューによって処理され最大のビットレートを指定します。この値は、親
の queue の値を超えてはいけなくて、親のキューの帯域幅の絶対値または
割合として指定することができます。指定されなければ、デフォルトは、
親のキューの帯域幅の 100% です。priq スケジューラは、帯域幅指定をサ
ポートしません。
priority <level>
キューの間で、優先順序レベルを設定することができます。cbq と hfsc
に関して、範囲は、0 から 7 であり、priq に関しては、範囲は、0 から
15 です。すべてのデフォルトは、1 です。より高い優先順序がある priq
キューは、常に最初に処理されます。より高い優先順序がある cbq と
hfsc キューは、オーバロードの場合が選ばれます。
qlimit <limit>
パケットの最大数は、キューに保持されます。デフォルトは、50 です。
scheduler は、<scheduler> (<parameters>)で追加パラメータを取得することが
できます。パラメータは、次の通りです:
default 別のキューによって適合されなかったパケットは、これに割り当て
られます。きっちり 1 つのデフォルトキューが必要です。
red このキューで RED (ランダムな早期発見 (Random Early Detec
tion)) を有効にします。RED は、平均したキューの長さに比例して
いる確率でパケットを落とします。
rio このキューで RIO を有効にします。RIO は、IN/OUT がある RED で
あり、したがって、RIO が同じ効果を達成するより 2 倍も多くの
RED を実行します。RIO は、現在、GENERIC カーネルでサポートさ
れていません。
ecn このキューで ECN (明白な混雑状態通知 (Explicit Congestion
Notification)) を有効にします。ECN は、RED を含意します。
cbq scheduler は、次の追加オプションをサポートします:
borrow キューは、親から帯域幅を取り入れることができます。
hfsc scheduler は、次のいくつかの追加オプションをサポートします:
realtime <sc>
キューに必要とする最小限の帯域幅。
upperlimit <sc>
キューに許された最大の帯域幅。
linkshare <sc>
バックログされたキューの共有された帯域幅。
<sc> は、service curve (サービスカーブ) の頭文字語です。
サービスカーブ仕様のための形式は、(m1, d, m2) です。m2 は、キューに割り当
てられた帯域幅を制御します。m1 と d は、省略可能であり、初期の帯域幅割り
当てを制御するために使用することができます。最初の d ミリセカンドに対し
て、キューは、m1 として与えられた帯域幅、その後 m2 で与えられた値を取得し
ます。
さらに、cbq と hfsc において、子供のキューは、altq 宣言のように指定するこ
とができ、その結果、それらの親の帯域幅の一部を使用してキューのツリーを構
築します。
パケットは、queue キーワードを使用することによってフィルタ規則に基づく
キューに割り当てることができます。通常、1 つの queue だけが指定されます。
2 番目のものが指定されるとき、それは、lowdelay の TOS を持っているパケッ
トとデータペイロードがない TCP ACK に代わりに使用されます。
前の例を続けるために、以下の例は、4 つの参照されたキューといくつかの子供
のキューを指定します。対話的な ssh(1) セッションは、scp(1) と sftp(1) の
ようなバルク転送より優先されます。そして、キューは、フィルタリング規則に
よって参照されます (下記のパケットフィルタリング参照)。
queue std bandwidth 10% cbq(default)
queue http bandwidth 60% priority 2 cbq(borrow red) \
{ employees, developers }
queue developers bandwidth 75% cbq(borrow)
queue employees bandwidth 15%
queue mail bandwidth 10% priority 0 cbq(borrow ecn)
queue ssh bandwidth 20% cbq(borrow) { ssh_interactive, ssh_bulk }
queue ssh_interactive bandwidth 50% priority 7 cbq(borrow)
queue ssh_bulk bandwidth 50% priority 0 cbq(borrow)
block return out on dc0 inet all queue std
pass out on dc0 inet proto tcp from $developerhosts to any port 80 \
queue developers
pass out on dc0 inet proto tcp from $employeehosts to any port 80 \
queue employees
pass out on dc0 inet proto tcp from any to any port 22 \
queue(ssh_bulk, ssh_interactive)
pass out on dc0 inet proto tcp from any to any port 25 \
queue mail
変換
変換規則は、ステートフル接続に関連しているパケットのソース (始点) または
宛先 (終点)アドレスのいずれかを変更します。ステートフル接続は、それらが
pf.conf のフィルタリングセクションによってブロックされない限り、そのよう
な規則に適合するパケットを追跡するために自動的に作成されます。変換エンジ
ンは、パケット中の指定されたアドレス、と/または、ポートを変更して、必要に
応じて IP、TCP と UDP チェックサムを再計算し、そして評価のためにパケット
フィルタにそれを渡します。
変換は、フィルタリングの前に生じるので、フィルタエンジンは、任意のアドレ
スとポートが変換された後で見るようなパケットを見ます。したがって、フィル
タ規則は、変換されたアドレスとポート番号に基づいてフィルタリングしなけれ
ばなりません。変換規則に適合するパケットは、pass 修飾子が与えられる場合に
だけ、自動的に渡されます、そうでなければ、それらは、まだ block と pass 規
則に従います。
作成された状態エントリは、pf(4) がその状態に関連しているトラフィックのた
めのオリジナルのアドレスの経過を追い、その接続のためのトラフィックを正し
く直接返すことを可能にします。
変換の様々なタイプは、次の pf で可能です:
binat
binat 規則は、外部の IP netblock と内部の IP netblock の間の双方向
のマッピングを指定します。
nat nat 規則は、IP アドレスがパケットが与えられたインタフェースを横断す
るときに変更されることを指定します。この技術で、変換しているホスト
に関する 1 つ以上の IP アドレスが、"内部 (inside)" のネットワークで
より大きい範囲のマシンのためにネットワークトラフィックをサポートで
きます。理論的には、任意の IP アドレスが内部で使用することができま
すが、RFC 1918 によって定義されたアドレスの範囲の 1 つが使用される
ことが強く勧められます。これらの netblocks は、次の通りです:
10.0.0.0 - 10.255.255.255 (all of net 10, i.e., 10/8)
172.16.0.0 - 172.31.255.255 (i.e., 172.16/12)
192.168.0.0 - 192.168.255.255 (i.e., 192.168/16)
rdr パケットは、別の宛先 (終点) とことによると異なったポートにリダイレ
クト (向け直し) されます。rdr 規則は、単一のポートの代わりにオプ
ションのポート範囲を指定することができます。rdr ... port 2000:2999
-> ... port 4000 は、2000 から 2999 (包括的) のポートをポート 4000
にリダイレクト (向け直し) します。rdr ... port 2000:2999 -> ...
port 4000:* は、2000 から 4000, 2001 から 4001, ..., 2999 のポート
を 4999 にリダイレクト (向け直し) します。
アドレスを変更することに加えて、いくつかの変換規則は、tcp(4) または
udp(4) 接続のためにソース (始点) または宛先 (終点) を変更します。nat 規則
の場合は、暗黙のうちに、rdr 規則の場合は、明示的に、変更します。ポート番
号は、binat 規則で決して変換されません。
翻訳規則の評価順序は、変換規則とパケットの方向のタイプに依存しています。
binat 規則は、常に最初に評価されます。次に、rdr 規則は、内向きのパケット
で評価されるか、または nat 規則は、外向きのパケットで評価されます。同じタ
イプの規則は、それらがルールセットに現れる同じ順序で評価されます。最初の
適合規則は、どんなアクションが取られるかを決定します。
変換規則へ前に置かれた no オプションは、パケットフィルタでの drop quick
動作とまったく同じように (下記参照)、パケットを変換されないままで残すよう
にします。どんな規則もパケットに適合しないなら、変更されていなでフィルタ
エンジンに渡されます。
変換規則は、指定されたインタフェースを通過するパケットだけに適用されま
す、インタフェースが指定されないなら、変換は、すべてのインタフェースでパ
ケットに適用されます。例えば、内部の web サーバに外部のインタフェースで
ポート 80 をリダイレクトする (向け直す) ことは外部から発する接続のためだ
けに動作します。ローカルホストからの外部インタフェースのアドレスとの接続
は、そのようなパケットが実際に外部のインタフェースを通過しなしので、リダ
イレクトされません。リダイレクションは、それらが到着するインタフェースを
通してパケットを反映することができないで、異なったインタフェースに接され
たホスト、または、ファイアウォール自体にそれらは、リダイレクトする (向け
直す) ことができるだけです。
事実上、次のように、
rdr on ne3 inet proto tcp to port smtp -> 127.0.0.1 port spamd
ループバックアドレスに外部の着信接続をリダイレクトすることは、本当のイン
タフェースにおけるそのような接続の伝統的なブロッキングを回避して、外部の
ホストが唯一ループバックアドレスへのバインドするデーモンに接続することを
可能とします。この効果が望まれていない場合、ローカルの非ループバックアド
レスのどれも、代わりに、このアドレスにバインドするか、またはどんなアドレ
スにもバインドしないデーモンだけに外部の接続を許す、リダイレクションター
ゲットとして使用されるべきです。
下記の変換の例を参照してください。
パケットフィルタリング
pf(4) には、それらのレイヤ (層) 3 (ip(4) と ip6(4) 参照) とレイヤ (層) 4
(icmp(4), icmp6(4), tcp(4), udp(4) 参照) ヘッダの属性に基づくパケットを
block (ブロック) して、pass (通過) する能力があります。さらに、また、パ
ケットは、帯域幅制御の目的のためのキューに割り当てられるかもしれません。
パケットフィルタによって処理された各パケットに関しては、フィルタ規則は、
最初から最後まで連続した順序で評価されます。最後に適合する規則は、どんな
アクションが取られるかを決定します。規則がパケットにマッチしないなら、デ
フォルトの動作は、パケットを通過することです。
次のアクションは、次のフィルタで使用することができます:
block
パケットは、ブロックされます。パケットをブロックするとき block (ブ
ロック) 規則が振る舞うことができる多くの方法があります。デフォルト
の振る舞いは、静かにパケットを drop (落とす) ことですが、しかしなが
ら、block-policy オプションを設定するか、または、次のオプションの 1
つに基づく規則毎に、上書きするか、明白にいずれかをグローバルにする
ことができます。
drop パケットは、静かに落とされます。
return-rst
これは、tcp(4) パケットのみ適用し、接続をクローズする TCP RST
を発行します。
return-icmp
return-icmp6
これは、ICMP メッセージを規則に適合するパケットのために返させ
ます。デフォルトで、これは、ICMP UNREACHABLE メッセージです
が、しかしながら、コードまたは数としてメッセージを指定するこ
とによって、これを無効にすることができます。
return
これは、tcp(4) パケットのために TCP RST を返えさせ、UDP と他
のパケットのためには、ICMP UNREACHABLE です。
pf(4) が if_bridge(4) で操作されるなら、ICMP パケットを返すオプショ
ンは、現在効果がありません。この機能をサポートするコードは、まだ実
装されていません。
デフォルトですべてをブロックし、明白な規則にマッチするパケットだけ
を通過する最も簡単なメカニズムは、次の最初のフィルタ規則を指定する
ことです:
block all
pass パケットは、通過されます。状態は、no state がオプションが指定されな
いなら、作成されます。
デフォルトで、pf(4) は、パケットをステートフルに (処理状態を把握する)
フィルタします。最初のパケットは、pass (通過) 規則にマッチし、状態エント
リが作成されます。その後のパケットに関して、フィルタは、パケットが任意の
状態にマッチするどうかチェックします。そうするなら、パケットは、任意の規
則の評価なしでも通過されます。接続がクローズされるか、タイムアウトの後
に、状態エントリは、自動的に削除されます。
これには、いくつかの利点があります。TCP 接続のために、パケットを状態と比
較することは、scrub reassemble tcp 規則が接続に適用されるなら、TCP タイム
スタンプと同様にシーケンス番号をチェックすることを必要とします。これらの
値が期待された値の狭いウィンドウの外であるなら、パケットは、落とされま
す。これは、攻撃者がにせのソースアドレス/ポートでパケットを送信するが、接
続のシーケンス番号を知らないときのような、なりすまし攻撃を防ぎます。同様
に、pf(4) は、どのように ICMP 応答を状態にマッチするかを知っています。例
えば、
pass out inet proto icmp all icmp-type echoreq
によって、(ping(8) によって作成されたもののように) エコー要求は、ステート
フルに出力でき、着信エコー応答が正しく状態にマッチします。
また、通常、状態の検索は、規則を評価するより速くなります。50 の規則がある
なら、それらのすべては、O(n) で連続して評価されます。50000 の状態があって
も、状態が O(log2n) で検索できる二分検索木に格納されるので、16 の比較だけ
が状態とマッチするために必要です。
さらに、ICMP エラーメッセージの正しい取り扱いは、多くのプロトコル、特に
TCP でクリティカル (重要) です。pf(4) は、ICMP エラーメッセージを正しい接
続に合わせて、接続パラメータに対してそれらをチェックして、適切であるな
ら、それらを渡します。例えば、ステートフル TCP 接続を参照する ICMP ソース
quench (クエンチ, 焼き入れ) メッセージが到着すると、それは、状態にマッチ
されて、通過されます。
最終的に、状態の追跡は、返って来るパケットでアドレスを追跡して、ポートを
変換し、変換を逆にするために、nat, binat と rdr 規則を必要とします。
また、pf(4) は、本来、事実上ステートレス (状態なし) である他のプロトコル
のための状態を作成します。UDP パケットは、ホストアドレスとポートだけを使
用して状態とマッチされ、他のプロトコルは、ホストアドレスだけを使用して状
態とマッチされます。
個々のパケットのステートレス (状態なし) フィルタリングが要求されているな
ら、これが最後の規則のマッチであるなら、状態が作成されないことを指定する
ために no state キーワードを使用することができます。また、pf(4) が状態の
追跡をどのように扱うかに影響するように多くのパラメータを設定することがで
きます。さらに詳しい詳細については、下記のステートフルトラッキングオプ
ションを参照してください。
パラメータ
規則パラメータは、規則が適用されるパケットを指定します。パケットは、常
に、1 つのインタフェースを通して入って来るか、または外に出ます。ほとんど
のパラメータは、オプションです。パラメータが指定されるなら、規則は、適合
する属性があるパケットのみに適用されます。特定のパラメータは、リストとし
て表すことができます、その場合、pfctl(8) は、すべての必要な規則の組み合わ
せを生成します。
in または out
この規則は、着信または発信パケットに適用されます。in も out も指定
されないなら、規則は、両方の方向にパケットに適合します。
log 指定されたアクションに加えて、ログメッセージが生成されます。no
state オプションが指定されないなら、状態を確立するパケットだけがロ
グ記録されます。ログ記録されたパケットは、デフォルトで pflog0 であ
る、pflog(4) インタフェースに送信されます。このインタフェースは、
pcap(3) バイナリ形式でファイル /var/log/pflog にログ記録されたパ
ケットをダンプする、pflogd(8) ログ記録デーモンによって、モニタされ
ます。
log (all)
接続のためにすべてのパケットのログ記録を強制するために使用されま
す。no state が明白に指定されるとき、これは、必要ではありません。
log のように、パケットは、pflog(4) にログ記録されます。
log (user)
パケットが、(どのソケットがローカルであるかにより) どこが発信元であ
るか、または、どこが宛先であるかで、オープンされたソケットがある、
ソケットとプロセスの PID を所有しているユーザの UNIX ユーザ ID をロ
グ記録します。これは、ログ記録された通常の情報に追加されます。
log (all, user) を通してログ記録された最初のパケットのみ、ステート
フルマッチング (stateful matching) を使用するとき、ログ記録された
ユーザ資格証明があります。
log (to <interface>)
ログを pflog0 の代わりに指定された pflog(4) インタフェースに送信し
ます。
quick
パケットが quick オプション設定がある規則に適合するなら、この規則
は、最後に適合する規則であると見なされ、その後の規則の評価は、ス
キップされます。
on <interface>
この規則は、この特定のインタフェースまたはインタフェースグループを
通して着信するか発信するパケットだけに適用されます。インタフェース
グループの詳しい情報に関しては、ifconfig(8) の group キーワードを参
照してください。
<af> この規則は、このアドレスファミリのパケットだけに適用されます。サ
ポートされた値は、inet と inet6 です。
proto <protocol>
この規則は、このプロトコルのパケットだけに適用されます。一般的なプ
ロトコルは、icmp(4), icmp6(4), tcp(4) と udp(4) です。pfctl(8) に
よって使用された数のマッピングへのすべてのプロトコル名のリストに関
しては、ファイル /etc/protocols を参照してください。
from <source> port <source> os <source> to <dest> port <dest>
この規則は、指定されたソース(始点)、宛先 (終点) アドレス、とポート
でパケットだけに適用されます。
アドレスは、シンボリックなホスト名、インタフェース名またはインタ
フェースグループ名として、または、次のキーワードのいずれかとして、
CIDR 記法 (netblocks に適合する) で指定することができます:
any 任意のアドレス。
no-route 現在経路制御可能でない任意のアドレス。
urpf-failed unicast reverse path forwarding (ユニキャスト逆パス
転送) (URPF) チェックに失敗する任意のソースアドレ
ス、すなわち、パケットのソースアドレスへ戻るルート
を保持する以外のインタフェースで着信するパケットで
す。
<table> 与えられたテーブルに適合する任意のアドレス。
アドレスの範囲は、`-' 演算子を使用することによって指定されます。例
えば: ``10.1.1.10 - 10.1.1.12'' は、10.1.1.10 から 10.1.1.12 までの
すべてのアドレスを意味し、したがって、アドレス 10.1.1.10、10.1.1.11
と 10.1.1.12 です。
インタフェース名とインタフェースグループ名は、次の修飾子を追加する
ことができます:
:network インタフェースにアタッチされた (複数の) ネットワーク
に変換します。
:broadcast インタフェースの (複数の) ブロードキャスト (同報通信)
アドレスに変換します。
:peer (複数の) ポイントツーポイントのインタフェースのピア
(相手) アドレスに変換します。
:0 インタフェース別名を含めません。
また、ホストの名前は、見つけられる各 v4 と v6 アドレスの最初に名前
解決を制限するために追加された :0 オプションがあります。
ホスト名解決とアドレス変換へのインタフェースは、ルールセットロード
時に行われます。インタフェース (または、ホスト名) のアドレスが変化
するとき (例えば DHCP か PPP の下で)、ルールセットは、変更をカーネ
ルに反映されるために再びロードされなければなりません。括弧中のイン
タフェース名 (と、オプションの修飾子) を囲むことは、この振る舞いを
変更します。インタフェース名が括弧で囲まれるとき、規則は、インタ
フェースがアドレスを変更するときはいつも自動的に更新されます。ルー
ルセットは、再びロードされる必要はありません。これは、nat で特に役
に立ちます。
ポートは、数か名前のいずれかによって指定することができます。例え
ば、ポート 80 は、www として指定することができます。pfctl(8) によっ
て使用された数のマッピングへのすべてのポート名のリストに関しては、
ファイル /etc/services を参照してください。
ポートのポートと範囲は、これらのオペレータを使用することによって指
定されます:
= (等しい)
!= (不等)
< (未満)
<= (以下)
> (越える)
>= (以上)
: (境界を含む範囲)
>< (境界を含まない範囲)
<> (範囲を除く)
`><', `<>' と `:' は、(2 つの引数を取る) 2 項演算子です。例えば:
port 2000:2004
`すべてのポート >= 2000 と <= 2004' したがって、ポート
2000、2001、2002、2003、と 2004 を意味します。
port 2000 >< 2004
`すべてのポート > 2000 と < 2004' したがって、ポート
2001、2002、と 2003 を意味します。
port 2000 <> 2004
`すべてのポート < 2000 または > 2004' したがって、ポー
ト 1-1999 と 2005-65535 を意味します。
ソースホストのオペレーティングシステムは、OS 修飾子がある TCP 規則
の場合に指定することができます。詳しい情報については、オペレーティ
ングシステム指紋法セクションを参照してください。
ホスト、ポート、と OS 仕様は、次の例のようにオプションです:
pass in all
pass in from any to any
pass in proto tcp from any port <= 1024 to any
pass in proto tcp from any to any port 25
pass in proto tcp from 10.0.0.0/8 port > 1024 \
to ! 10.1.2.3 port != ssh
pass in proto tcp from any os "OpenBSD"
all これは、"from any to any" と同等です。
group <group>
user と同様に、この規則は、指定されたグループによって所有されている
ソケットのパケットのみに適用します。
user <user>
この規則は、指定されたユーザによって所有されているソケットのパケッ
トのみに適用します。ファイアウォールから開始された発信接続におい
て、これは、接続をオープンしたユーザです。ファイアウォール自体への
着信接続のために、これは、宛先 (終点) ポートで listen する (接続を
受け付ける) ユーザです。転送された接続において、ファイアウォールが
接続された終点でないところで、ユーザとグループは、unknown (未知) で
す。
1 つの接続の発信と着信のすべてのパケットは、同じユーザとグループに
関連付けられます。TCP と UDP パケットしかユーザに関連付けることはで
きません。他のプロトコルにおいて、これらのパラメータは、無視されま
す。
ユーザとグループは、ソケットが setuid/setgid プロセスによって作成さ
れるときに備えて、有効な (実際とは対照的に) ID を参照します。ユーザ
とグループ ID は、ソケットが作成されるとき、保存されます。プロセス
がルート (例えば、特権があるポートにバインドすることによって) とし
て listen (接続を受け付け) ソケットを作成し、その次に別のユーザ ID
(特権を下げる) を変更するとき、資格証明は、ルートのままで残ります。
ユーザとグループ ID は、数か名前のどちらかで指定することができま
す。構文は、ポートのものと同様です。unknown (未知の) 値は、転送され
た接続のパケットに適合します。unknown は、オペレータ = と != でのみ
使用することができます。user >= unknown のような他の構文は、無効で
す。unknown (未知の) ユーザとグループ ID で転送されたパケットは、オ
ペレータ = または != と反対の明白な比較である規則のみに適合します。
例えば、user >= 0 は、転送されたパケットに適合しません。次の例は、
選択されたユーザだけが発信接続をオープンできます:
block out proto { tcp, udp } all
pass out proto { tcp, udp } all user { < 1000, dhartmei }
flags <a> /<b> | /<b> | any
この規則は、flags <a> が設定され <b> が設定されない、TCP パケットだ
けに適用されます。<b> で指定されなかった flags は、無視されます。ス
テートフル接続において、デフォルトは、flags S/SA です。フラグが、す
べてチェックされるべきでないことを示すためには、flags any を指定し
ます。flags は、次の通りです: (F)IN, (S)YN, (R)ST, (P)USH, (A)CK,
(U)RG, (E)CE と C(W)R です。
flags S/S フラグ SYN が設定されます。他のフラグは、無視されます。
flags S/SA これは、ステートフル接続のためのデフォルトの設定です。
SYN と ACK 以外、正確に SYN が設定されます。SYN,
SYN+PSH と SYN+RST は、適合しますが、SYN+ACK, ACK と
ACK+RST は、適合しません。これは、前の例より制限されて
います。
flags /SFRA
最初の設定が指定されないなら、それは、なにもをデフォル
トとしません。すべての SYN, FIN, RST と ACK は、設定し
てはいけません。
(no state が指定されないなら) flags S/SA がデフォルトで適用されるの
で、TCP ハンドシェイクの初期の SYN パケットだけが TCP 接続のために
状態を作成します。それを制限することはでき、flags any を指定するこ
とによって中間的な (non-SYN) パケットからの状態の作成することは可能
です。例えば、ステートテーブルをフラッシュするなら、これによって、
pf(4) は、既存の接続に同期します。しかしながら、そのような中間的パ
ケットから作成された状態は、TCP ウィンドウのスケールファクタのよう
な詳細な接続を失うかもしれません。それらが nat, binat または rdr 規
則、modulate または synproxy state オプション、または reassemble
tcp で無効にされるかによって影響されるようなパケットフローを変更す
る状態も、中間的パケットから復旧可能ではありません。そのような接続
は、ストール (行き詰まり) しタイムアウトします。
icmp-type <type> code <code>
icmp6-type <type> code <code>
この規則は、指定されたタイプとコードがある ICMP か ICMPv6 パケット
だけに適用されます。ICMP タイプとコードのためのテキスト名は、
icmp(4) と icmp6(4) にリストされています。このパラメータは、プロト
コル ICMP か ICMP6 をカバーする規則だけに有効です。プロトコルと
ICMP タイプ指示子 (icmp-type または icmp6-type) は、適合しなければ
なりません。
tos <string> | <number>
この規則は、指定された TOS ビットの設定でパケットに適用されます。
TOS は、critical, inetcontrol, lowdelay, netcontrol, throughput,
reliability の 1 つとして、または DiffServ Code Points の 1 つとし
て与えられます: ef, af11 ... af43, cs0 ... cs7; または 16 進数また
は 10 進数のいずれかとして。
例えば、次の規則は、同じです:
pass all tos lowdelay
pass all tos 0x10
pass all tos 16
allow-opts
デフォルトで、IP オプションがある IPv4 パケットまたはルーティング拡
張ヘッダがある IPv6 パケットは、ブロックされます。allow-opts が
pass 規則のために指定されるとき、その規則 (最後のマッチング) に基づ
いてフィルタに渡すパケットは、たとえ、それらが、IP オプションか、ま
たはルーティング (経路制御) 拡張ヘッダを含んでも、そうします。状態
に適合するパケットに関しては、初めに状態を作成した規則が使用されま
す。パケットがどんな規則にも適合しないとき使用される暗黙の pass 規
則は、IP オプションを許可しません。
label <string>
規則を識別するために使用することができる、ラベル (名) を規則に追加
します。例えば、pfctl -s labels は、ラベルを持っている規則のために
規則ごとの統計を表示します。
次のマクロは、ラベルで使用することができます:
$if インタフェース。
$srcaddr ソース (始点) IP アドレス。
$dstaddr 宛先 (終点) IP アドレス。
$srcport ソース (始点) ポート指定。
$dstport 宛先 (終点) ポート指定。
$proto プロトコル名。
$nr 規則番号。
例えば:
ips = "{ 1.2.3.4, 1.2.3.5 }"
pass in proto tcp from any to $ips \
port > 1023 label "$dstaddr:$dstport"
は、次のように拡張されます。
pass in inet proto tcp from any to 1.2.3.4 \
port > 1023 label "1.2.3.4:>1023"
pass in inet proto tcp from any to 1.2.3.5 \
port > 1023 label "1.2.3.5:>1023"
==================================--- label 指示のためのマクロ展開
は、設定ファイルの解析時のみに起こり、実行時ではありません。
queue <queue> | (<queue>, <queue>)
この規則に適合するパケットは、指定されたキューに割り当てられます。2
つのキューが与えられるなら、データのペイロードなしで lowdelay の
TOS と TCP ACK を持っているパケットは、2 番目のものに割り当てられま
す。訳注: ペイロードは、転送されるパケットのヘッダ部を除いたデータ
の本体。セットアップの詳細については、キューイング参照してくださ
い。
例えば:
pass in proto tcp to port 25 queue mail
pass in proto tcp to port 22 queue(ssh_bulk, ssh_prio)
set prio priority | (priority, priority)
この規則と一致しているパケットは、特有なキューイング (queueing) 優
先度を割り当てられます。優先度は、0 から 7 までの整数として割り当て
られます。パケットが vlan(4) インタフェースで転送されるなら、キュー
イング (queueing) 優先度は、802.1Q VLAN ヘッダの優先度コードポイン
トとして書き込まれます。2 つの優先度が与えられるなら、lowdelay の
TOS があるパケットとペイロードされたデータがない TCP ACK は、2 番目
のものに割り当てられます。
例えば、次の通りです:
pass in proto tcp to port 25 set prio 2
pass in proto tcp to port 22 set prio (2, 5)
tag <string>
この規則に適合するパケットは、指定された文字列でタグ付けされます。
タグは、後でこれらのパケットを特定するために使用することができる内
部のマーカとして作用します。例えば、インタフェースの間の信任を提供
するためと、パケットが変換規則で処理されたかどうか決定するためにこ
れを使用することができます。規則が最後の適合する規則でなくても、パ
ケットがタグ付けをされることを意味して、タグは、"sticky" (ねばねば)
です。さらに、適合している規則は、新しいものでタグを置き換えること
ができますが、以前に適用されたタグは、取り除かれません。パケット
は、一度に 1 個のタグしか割り当てられません。パケットは、フィルタ規
則に加えて nat, rdr または binat 規則の間にタグ付けすることができま
す。タグは、ラベルと同じマクロを取ります (上記参照)。
tagged <string>
パケットが規則にマッチするために与えられたタグで既にタグ付けをしな
ければならないと指定するためにフィルタ、変換または scrub 規則で使用
されます。また、反対のタグの適合は、tagged (タグ付け) されたキー
ワードの前に ! オペレータを指定することによって行うことができます。
rtable <number>
ルーティング (経路制御) 検索のために代替ルーティングテーブルを選択
するために使用します。ルート (経路) 検索が起こるまえだけ有効となり
ます、すなわち、内向きフィルタリングのとき。
divert-to <host> port <port>
パケットを host と port をバインドするローカルソケットにリダイレク
トするために使用します。パケットは、変更されないので、ソケット上の
getsockname(2) は、パケットのオリジナルの宛先アドレスを返します。
divert-reply
マシンにローカルでないアドレスにバインドされるソケットのための応答
を受信するために使用します。どのようにこれらのソケットをバインドす
るかの情報については、setsockopt(2) を参照してください。
probability <number>
確率属性は、領域は、含まず、0 と 1 の間で設定された値で規則にアタッ
チすることができます。その場合には、規則は、与えられた確率値だけを
使用することで尊敬されます。例えば、次の規則は、20% の着信 ICMP パ
ケットを落します:
block in proto icmp probability 20%
prio <number>
与えられたキューイング (queueing) 優先度がある一致するパケットだけ
を割り当てました。
(ルーティング) 経路制御
パケットがルート (経路) オプション設定で規則に適合するなら、パケットフィ
ルタは、ルートオプションのタイプに従ってパケットを (ルーティング) 経路制
御します。そのような規則が状態を作成するとき、ルートオプションは、また、
同じ接続に適合するすべてのパケットに適用されます。
route-to
route-to オプションは、パケットを次の中継点のための省略可能なアドレ
スで指定されたインタフェースへ経路制御します。route-to 規則が状態を
作成するとき、フィルタ規則指定と同じ方向に通過するパケットだけが、
この方法で経路制御されます。逆方向 (応答) に通過するパケットは、影
響を受けないで、正常に経路制御されます。
reply-to
reply-to オプションは、route-to オプションと同様ですが、指定された
インタフェースへの逆方向 (応答) に通過するパケットを経路制御しま
す。逆方向は、状態エントリのコンテキストでのみ定義され、reply-to
は、状態を作成する規則でのみ、役に立ちます。(左右対称の経路制御施
行) を通して到着した着信接続のインタフェースを通して接続のすべての
発信パケットを経路制御するために複数の外部の接続と共にシステムで使
用することができます。
dup-to
dup-to オプションは、パケットの複製を作成して、それを route-to のよ
うに経路制御します。オリジナルのパケットは、普通に経路制御されるよ
うに経路制御されます。
プールオプション
(1 つ以上の IP アドレス) IPv4 のための 32 または IPv6 のための 128 より小
さなサブネットマスクがある単一のリダイレクションアドレスがある (route-to,
reply-to と dup-to 規則オプションと同様に) nat と rdr 規則のために、この
アドレスを割り当てるためのさまざまな異なった方法は、次のように使用するこ
とができます:
bitmask
bitmask オプションは、リダイレクションアドレスのネットワーク部分を
(nat があるソース (始点)、rdr がある宛先 (終点)) で変更されるための
アドレスに適用します。
random
random オプションは、アドレスの定義されたブロック中でランダムにアド
レスを選択します。
source-hash
source-hash オプションは、リダイレクションアドレスが与えられたソー
ス (始点) と常に同じであることを確実にするために、リダイレクション
アドレスを決定するのにソース (始点) アドレスのハッシュを使用しま
す。オプションキーは、16 進数か文字列として、このキーワードの後に指
定することができます。デフォルトで、pfctl(8) は、ルールセットが再
ロードされるときはいつも、source-hash のためにキーをランダムに生成
します。
round-robin
round-robin オプションは、(複数の) リダイレクションアドレスを通して
ループします。
1 つ以上のリダイレクションアドレスが指定されるとき、round-robin
は、唯一の許可されたプールタイプです。
static-port
nat 規則で、static-port オプションは、pf(4) が TCP と UDP パケット
でソース (始点) ポートを変更するのを防ぎます。
さらに、sticky-address オプションは、同じソースからの複数の接続が同じリダ
イレクションアドレスにマップされることを確実にすることを助けるために指定
することができます。このオプションは、random と round-robin プールオプ
ションで使用することができます。それらを参照する状態がもはやないなら、す
ぐに、デフォルトで、これらの関連性が破壊されることに注意してください。状
態の存続期間を越えて最後にマッピングを作成するためには、set timeout
src.track でグローバルなオプションを増加させます。ソース追跡を制御するよ
り多くの方法については、ステートフル (処理状態の把握) トラッキング (追跡)
オプションを参照してください。
状態調節
TCP に由来するセキュリティの多くは、初期のシーケンス番号 (ISN) がどれくら
いよく選ばれているかに起因します。いくつかのよく知られているスタックの実
装は、非常に貧しい ISN を選んで、その結果、通常、ISN 予測エクスプロイト
(セキュリティ上の弱点を突く手段) を受け入れる余地があります。TCP 接続への
modulate state を適用することによって、pf(4) は、それぞれの接続終点のため
の高品質のランダムシーケンス番号を作成します。
modulate state 指示は、暗黙のうちに規則で状態を保持して、TCP 接続のみに適
用できます。
例えば:
block all
pass out proto tcp from any to any modulate state
pass in proto tcp from any to any port 25 flags S/SFRA modulate state
変調された接続は、状態テーブルが失われるとき (ファイアウォールリブート、
状態テーブルのフラッシュ、など) 復旧しないことに注意してください。pf(4)
は、状態テーブルが接続の調節子をフラッシュした後に再び接続を推論すること
ができません。状態が失われるとき、接続は、個別の終点の接続タイムアウトま
でぶら下げたままになるかもしれません。調節子の損失の後に再同期しようとし
ている間に ACK 攻撃を開始する終点のための速いローカルネットワークで可能で
す。デフォルト flags 設定 (または、より厳密な同等物) は、ACK 攻撃を防ぐた
めに modulate state 規則で使用されるべきです。
代替のメソッドは、状態テーブルの損失を防いで、ファイアウォールフェイル
オーバを可能とするために利用可能であることに注意してください。さらなる詳
細については、carp(4) と pfsync(4) を参照してください。
SYN プロキシ
デフォルトで、pf(4) は、終点の間で tcp(4) ハンドシェイクの不可欠な要素で
あるパケットを通過させます。synproxy state オプションは、pf(4) 自体がアク
ティブな終点でハンドシェイクを終了させるために、受動的な終点でハンドシェ
イクを実行して、次に、終点の間でパケットを転送するために、使用することが
できます。
アクティブな終点がハンドシェイクを終了する前には、パケットを受動的な終点
に送信しません、したがって、なりすましたソース (始点) アドレスでのいわゆ
る SYN 送り付け攻撃は、送信者がハンドシェイクを終了することができないと
き、受動的な終点に到達しません。
プロキシは、両方の終点に透明であり、それらは、それぞれ終点からの単一の接
続/終点への単一の接続に見えます。pf(4) は、両方のハンドシェイクのためのラ
ンダム初期シーケンス番号を選びます。ハンドシェイクがいったん終了される
と、シーケンス番号調節子 (前のセクションを参照) は、接続のさらなるパケッ
トを変換するために使用されます。synproxy state は、modulate state を含ん
でいます。
synproxy がある規則は、pf(4) が bridge(4) で動作するなら、動作しません。
例えば:
pass in proto tcp from any to any port www synproxy state
ステートフル (処理状態の把握) トラッキング (追跡) オプション
ステートフル追跡に関連する多くのオプションは、規則毎をベースにして適用す
ることができます。keep state, modulate state と synproxy state は、それら
のオプションをサポートし、keep state は、オプションを規則に適用するために
明白に指定しなければなりません。
max <number>
同時に規則を作成する状態の数の制限。この制限に到達するとき、状態を
作成するさらなるパケットは、存在する状態のタイムアウトまで、この規
則にマッチしません。
no-sync
pfsync(4) インタフェースで現れるのを、この規則によって作成された状
態への状態の変更を防ぎます。
<timeout> <seconds>
この規則によって作成された状態のために使用されるタイムアウトを変更
します。すべての有効なタイムアウト名のリストに関しては、上記のオプ
ションを参照してください。
sloppy
挿入と ICMP 分解攻撃 (teardown attack) をより簡単にする、シーケンス
番号を全くチェックしないずさんな (sloppy) TCP 接続トラッカ
(tracker) を使用します。これは、誰も接続のすべてのパケットを見ない
状況で、例えば、非対称のルーティング状況で、使用されることを目的と
しています。modulate または synproxy state で使用することはできませ
ん。
複数のオプションは、コンマによって分離して指定することができます:
pass in proto tcp from any to any \
port www keep state \
(max 100, source-track rule, max-src-nodes 75, \
max-src-states 3, tcp.established 60, tcp.closing 5)
source-track キーワードが指定されるとき、ソース IP 毎の状態の数は、追跡さ
れます。次の制限を設定することができます:
source-track rule
この規則で作成された状態の最大数は、規則の max-src-nodes と max-
src-states オプションによって制限されます。この特定の規則によって作
成された状態のエントリだけが規則の制限方向にカウントされます。
source-track global
このオプションを使用するすべての規則によって作成された状態の数は、
制限されます。各規則は、異なった max-src-nodes と max-src-states オ
プションを指定することができますが、任意の参加規則によって作成され
た状態のエントリは、それぞれの個別の規則の制限方向にカウントされま
す。
次の制限は、設定することができます:
max-src-nodes <number>
同時に状態テーブルエントリを持つことができる発信元アドレスの最大数
の制限。
max-src-states <number>
単一の発信元アドレスがこの規則で作成することができる同時に存在する
状態エントリの最大数の制限。
また、ステートフル TCP 接続において、(TCP 3-way ハンドシェイクが終了した
接続) を確立した接続での制限は、発信元 IP ごとに強制することができます。
max-src-conn <number>
単一のホストで行うことができる 3-way ハンドシェイクを終了した同時に
存在する TCP 接続の最大数の制限。
max-src-conn-rate <number> / <seconds>
時間間隔での、新しい接続の速度の制限。接続速度は、移動平均として計
算された近似値です。
3-way ハンドシェイクは、発信元アドレスがなりすましされていないことを確実
にするので、これらの制限に基づいて、より攻撃的な行動を取ることができま
す。overload <table> 状態のオプションで、確立された接続における制限のいず
れかにヒットする発信元 IP アドレスは、名前付けされたテーブルに追加されま
す。このテーブルは、それを tarpit プロセスにリダイレクトするか、またはそ
の帯域幅を制限する、問題となるホストからさらなる活動をブロックするための
ルールセットで使用することができます。
オプションの flush キーワードは、これらの制限を超えるホストから発するマッ
チング規則によって作成されたすべて状態を kill します。flush コマンドへの
global 修飾子は、どの規則が状態を作成したかにかかわらず、問題となっている
ホストから発するすべての状態を kill します。
例えば、次の規則は、10 秒で 100 個以上の接続を行うホストに対して WEB サー
バを保護します。この速度より早い接続のすべてのホストは、そのアドレスを
<bad_hosts> テーブルに追加し、フラッシュされたホストから発するすべての状
態を持ちます。このホストから到着するすべての新しいパケットは、ブロック規
則によって無条件に落とされます。
block quick from <bad_hosts>
pass in on $ext_if proto tcp to $webserver port www keep state \
(max-src-conn-rate 100/10, overload <bad_hosts> flush global)
オペレーティングシステム指紋法
受動的な OS 指紋法は、TCP 接続の初期の SYN パケットのニュアンス (微妙な差
異) を検査して、ホストのオペレーティングシステムを推測するメカニズムで
す。残念ながら、これらのニュアンスは、攻撃者によって容易に偽造されるの
で、指紋は、セキュリティを決定にする際に役に立ちません。しかし、通常、指
紋は、ポリシ決定を行うために十分正確です。
指紋は、オペレーティングシステムのクラス、バージョン、またはサブタイプ/
パッチレベルによって指定されます。オペレーティングシステムのクラスは、通
常ベンダかジャンルであり、pf(4) ファイアウォール自体への OpenBSD となるで
しょう。主な FTP サイトで最も古い利用可能な OpenBSD リリースのバージョン
が 2.6 となり、指紋は、次のように書かれるでしょう。
"OpenBSD 2.6"
オペレーティングシステムのサブタイプは、そのパッチが TCP スタックの振る舞
いでの変更となるなら、通常、パッチレベルについて説明するために使用されま
す。OpenBSD の場合には、唯一のサブタイプは、no-df 無効オプションによって
正常化にされた指紋のためであり、次のように指定されるでしょう。
"OpenBSD 3.3 no-df"
ほとんどの一般的なオペレーティングシステムのための指紋は、pf.os(5) によっ
て提供されます。いったん pf(4) が実行さると、知られているオペレーティング
システム指紋のすべてのリストは、次のように実行することによってリストされ
ます:
# pfctl -so
フィルタ規則は、指紋が存在していると仮定する任意のレベルのオペレーティン
グシステム仕様においてポリシを実行することができます。ポリシは、承認され
たオペレーティングシステムへのトラフィックか、または最も遅いサービスパッ
クを攻撃しないホストからの接続を禁止するトラフィックさえ、制限するかもし
れません。
また、unknown クラスは、オペレーティングシステム指紋が知られていないパ
ケットに適合する指紋として使用することができます。
例えば:
pass out proto tcp from any os OpenBSD
block out proto tcp from any os Doors
block out proto tcp from any os "Doors PT"
block out proto tcp from any os "Doors PT SP3"
block out from any os "unknown"
pass on lo0 proto tcp from any os "OpenBSD 3.3 lo0"
オペレーティングシステム指紋は、TCP SYN パケットだけに制限されます。これ
は、他のプロトコルで動作しないで、現在確立した接続に適合しないことを意味
します。
警告: オペレーティングシステム指紋は、時々間違っています。3 つの問題があ
ります: 攻撃者は、彼が選ぶどんなオペレーティングシステムとしても現れるよ
うにパケットを巧妙に作ることができます。オペレーティングシステムパッチ
は、スタックの振る舞いを変更するかもしれません、そして、どんな指紋もデー
タベースを更新するまでそれに適合しないでしょう。そして、複数のオペレー
ティングシステムには、同じ指紋があるかもしれません。
なりすましトラフィックのブロック
"なりすまし" は、通常、悪意がある目的のための IP アドレスを偽造することで
す。antispoof 指示は、その他のインタフェースを通してシステムに入ってく
る、直接接続された (複数の) ネットワークから指定された (複数の) インタ
フェースまでソース IP ですべてのトラフィックをブロックする 1 組のフィルタ
規則を拡張します。
例えば、次の行
antispoof for lo0
は、次のように拡張します。
block drop in on ! lo0 inet from 127.0.0.1/8 to any
block drop in on ! lo0 inet6 from ::1 to any
非ループバックインタフェースには、インタフェースの IP と同じソース IP ア
ドレスで着信パケットをブロックするための追加規則があります。例えば、イン
タフェース wi0 が 10.0.0.1 の IP アドレスで 255.255.255.0 のネットマスク
(netmask) があると仮定すれば、次の行
antispoof for wi0 inet
は、次のように拡張します。
block drop in on ! wi0 inet from 10.0.0.0/24 to any
block drop in inet from 10.0.0.1 to any
警告: antispoof 指示で作成された規則は、ローカルのアドレスへのループバッ
クインタフェースに送信されたパケットを妨ぎます。明らかにこれらを通過する
べきです。
フラグメント操作
IP データグラム (パケット) のサイズは、ネットワークの最大の転送単位 (MTU)
よりかなり大きくなる場合があります。そのような大きいパケットを送信するた
めに、必要であるか、またはより効率的である場合では、大きなパケットは、接
続でそれぞれに適合する多くのより小さいパケットに断片化されます。残念なが
ら、ファイアウォールを行うデバイスに関して、最初の論理的な断片だけが
pf(4) が TCP ポートのようなものでフィルタにかけるか、または NAT を実行で
きるようにする、サブプロトコルのために必要なヘッダ情報を含みます。
上記のトラフィックの正常化で説明されている scrub 規則の使用のほかに、パ
ケットフィルタでフラグメントを操作するための 3 つのオプションがあります。
1 つの代替手段は、フィルタ規則で個々の断片をフィルタにかけることです。
scrub 規則が断片に適用されないなら、それは、フィルタを通過します。適合し
ている IP ヘッダパラメータがあるフィルタ規則は、完全なパケットがフィルタ
されるのと同じ方法で、断片が通過されるがブロックされるかどうかを決定しま
す。再構築なしに、断片は、サブプロトコルヘッダフィールドが利用可能でない
ので (TCP/UDP ポート番号、ICMP コード/タイプ)、IP ヘッダフィールド (ソー
ス/宛先アドレス、プロトコル) に基づいてのみフィルタにかけることができま
す。fragment オプションは、完全なパケットではなく、断片だけに適用するフィ
ルタ規則を制限するために使用することができます。fragment オプションのない
フィルタ規則は、IP ヘッダフィールドを指定するだけであるなら、それでも断片
に適用されています。例えば、規則
pass in proto tcp from any to any port 80
は、再構築なしでこの情報が各断片で利用可能でないので、断片が宛先のポート
80 で TCP パケットの部分であっても、決して断片に適用しません。また、これ
は、断片が新しいか、または適合する既存の状態テーブルエントリを作成するこ
とができないことを意味します。状態テーブルエントリは、断片のためのステー
トフルのフィルタリングとアドレス変換 (NAT、リダイレクション) を不可能にし
ます。
scrub 規則によるパラメータとしてソース、宛先アドレスまたはプロトコルを指
定することによって、特定の断片だけを再構築することも可能です。
多くの場合、再構築は、追加メモリ費用を越える利益があり、そして fragment
reassemble 修飾子を通してすべての断片を再構築する scrub 規則を使用するこ
とが勧められます。
断片キャッシュのために割り付けられたメモリは、pfctl(8) を使用して制限する
ことができます。いったんこの制限に到達するなら、キャッシュされなければな
らない断片は、他のエントリがタイムアウトするまで落とされます。また、タイ
ムアウト値を調整することもできます。
IPv6 パケットを再び組み立てられた転送のとき、pf は、オリジナルの最大の断
片のサイズでそれらを再断片化します。これによって、送信側は、パス MTU 発見
によって最適な断片サイズを決定することができます。
アンカ
主なルールセットのほかに、pfctl(8) は、ルールセットを anchor 取り付けポイ
ントにロードすることができます。anchor は、規則を保持することができるコン
テナ (入れ物)、アドレステーブルと、他のアンカです。
anchor には、pfctl(8) が、子供のアンカかローディング規則をアタッチするよ
うな、操作を実行するためにアンカにアクセスするために使用することができる
パスを指定する名前があります。アンカは、ファイルシステム階層構造がどのよ
うにレイアウトされているかと同様に、コンポーネントが `/' 文字よって分離さ
れて入れ子にされています。主なルールセットは、実際にデフォルトのアンカで
あるので、例えば、フィルタと変換規則は、任意のアンカにも含まれるかもしれ
ません。
アンカは、次の種類の規則を使用して別の anchor アタッチメントポイントを参
照することができます:
nat-anchor <name>
指定された anchor で nat 規則を評価します。
rdr-anchor <name>
指定された anchor で rdr 規則を評価します。
binat-anchor <name>
指定された anchor で binat 規則を評価します。
anchor <name>
指定された anchor でフィルタ規則を評価します。
load anchor <name> from <file>
指定されたファイル (file) からルールをアンカ name にロードします。
主なルールセットの評価が anchor 規則に到達するとき、pf(4) は、そのアンカ
で指定されたすべての規則を評価し続けます。
quick オプションでマークされるフィルタのマッチングと変換規則は、最終であ
り、他のアンカと主なルールセットの規則の評価を中止します。anchor 自体が
quick オプションでマークされるなら、ルールセットの評価は、パケットがアン
カ内の任意の規則にマッチされるなら、アンカが終了されるとき、終了します。
anchor 規則は、それらが含まれているアンカに相対的に評価されます。例えば、
主なルールセットで指定されたすべての anchor 規則は、主なルールセットの下
部のアンカアタッチメントポイントを参照し、load anchor 規則からロードされ
たファイルで指定された anchor 規則は、そのアンカポイントの下にアタッチさ
れます。
規則は、主なルールセットがロードされるとき、どんな規則も含まない anchor
アタッチメントポイントに含まれるかもしれません、そして、後で、そのような
アンカは、主なルールセットか他のアンカを再ロードしないで pfctl(8) を通し
て操作することができます。例えば、
ext_if = "kue0"
block on $ext_if all
anchor spam
pass out on $ext_if all
pass in on $ext_if proto tcp from any \
to $ext_if port smtp
は、デフォルトで外部のインタフェースでのすべてのパケットをブロックして、
次に、"spam" と名前が付けられた anchor ですべての規則を評価して、最後に
ポート 25 へのすべての発信接続と着信接続を通過します。
# echo "block in quick from 1.2.3.4 to any" | \
pfctl -a spam -f -
これは、単一の規則を特定のアドレスからすべてのパケットをブロックする、
anchor にロードします。
また、アンカは、anchor 規則の後に load anchor 規則を加えることによって、
投入することができます:
anchor spam
load anchor spam from "/etc/pf-spam.conf"
また、pfctl(8) が pf.conf をロードするとき、すべての規則をファイル
/etc/pf-spam.conf からアンカにロードします。
オプションで、anchor 規則は、フィルタ規則と同じ構文を使用してパケットフィ
ルタリングパラメータを指定することができます。パラメータが使用されると
き、anchor 規則は、適合するパケットのためだけに評価されます。これは、次の
ようなアンカの条件付きの評価を可能とします:
block on $ext_if all
anchor spam proto tcp from any to any port smtp
pass out on $ext_if all
pass in on $ext_if proto tcp from any to $ext_if port smtp
anchor spam 中の規則は、宛先のポート 25 で tcp パケットのためにだけに評価
されます。したがって、
# echo "block in quick from 1.2.3.4 to any" | \
pfctl -a spam -f -
は、1.2.3.4 からポート 25 までの接続だけをブロックします。
アンカは、それらのアンカ名のアルファベット順で評価されるべきであるそのポ
イントにアタッチされたすべてのアンカをを意味する、アスタリスク (`*') 文字
で終わるかもしれません。例えば、
anchor "spam/*"
は、spam アンカにアタッチされている各アンカの各規則を評価します。それは、
spam アンカに直接アタッチされているアンカを評価するだけであって、アンカを
再帰的に評価するために降りて行かないことに注意してください。
アンカがそれらが含まれているアンカに相対的に評価されるので、与えられたア
ンカの親と先祖のアンカにアクセスするためのメカニズムがあります。ファイル
システムパス名解決と同様に、シーケンス ``..'' は、アンカパスコンポーネン
トとして現れ、そのポイントでのパスの評価の現在のアンカの親のアンカは、新
しい現在のアンカになります。例として、次を熟考してください:
# echo ' anchor "spam/allowed" ' | pfctl -f -
# echo -e ' anchor "../banned" \n pass' | \
pfctl -a spam/allowed -f -
主なルールセットの評価は、spam/allowed アンカに導きます。そのアンカは、も
しあれば、最終的に pass 規則を評価する前に、spam/banned アンカで規則を評
価します。
大括弧 ('{' '}') で区切られたブロック内のルールセットのインラインでフィル
タ規則 anchors をロードすることができます。大括弧で区切られたブロックは、
規則または他の大括弧で区切られたブロックを含むことができます。アンカがこ
の方法でロードされるとき、アンカ名は、省略可能となります。
anchor "external" on egress {
block
anchor out {
pass proto tcp from any to port { 25, 80, 443 }
}
pass in proto tcp to any port 22
}
`/' 文字を含むアンカ名のどんな参照も、アンカ名のためのパーサ仕様が文字列
であるので、アンカ名の周りに二重引用符 (`"') 文字を必要とします。
変換の例
この例は、(例えば、root として実行されないので、したがって、ポート 80 を
バインドするパーミッションが不足するので) デーモンが実行される、ポート 80
からポート 8080 で着信要求をマップします。
# 容易に変更できるように、インタフェース名のためのマクロを使用します
ext_if = "ne3"
# 80 にあるように見えるように 8080 でデーモンをマップします
rdr on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 port 8080
pass 修飾子が与えられるなら、変換規則に適合するパケットは、次のフィルタ規
則を検査しないで、通過されます:
rdr pass on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 \
port 8080
以下の例では、vlan12 は、192.168.168.1 として設定されます。マシンは、それ
らが vlan12 を除いて、任意のインタフェースで外に出ていくとき、
192.168.168.0/24 から 204.92.77.111 に来るすべてのパケットを変換します。
これは、192.168.168.0/24 ネットワークからのトラフィックをまるで、vlan12
上のノードを除いて、ルータでの任意のインタフェースの後ろのノードにイン
ターネットの経路制御 (ルート) 可能なアドレス 204.92.77.111 であるかのよう
に、見えさせるというネットの効果があります。(したがって、192.168.168.1
は、192.168.168.0/24 ノードと通信することができます。)
nat on ! vlan12 from 192.168.168.0/24 to any -> 204.92.77.111
以下の例で、マシンは、にせの内部の 144.19.74.* ネットワークと
204.92.77.100 の経路制御可能な外部の IP の間にあります。no nat 規則は、プ
ロトコル AH を変換されることから除外します。
# NO NAT
no nat on $ext_if proto ah from 144.19.74.0/24 to any
nat on $ext_if from 144.19.74.0/24 to any -> 204.92.77.100
以下の例では、パケットは、sysadmin によって生成されたものがプロキシされな
いのと同様に、ある特定のサーバのためにバインドします。他のすべての接続
は、つぎの通りです。
# NO RDR
no rdr on $int_if proto { tcp, udp } from any to $server port 80
no rdr on $int_if proto { tcp, udp } from $sysadmins to any port 80
rdr on $int_if proto { tcp, udp } from any to any port 80 -> 127.0.0.1 \
port 80
このより長い例は、NAT とリダイレクションの両方を使用します。外部のインタ
フェースには、アドレス 157.161.48.183 があります。localhost では、我々
は、FTP セッションがそれにリダイレクトされるのをウェート (待つ) し、ftp-
proxy(8) を実行します。ftp-proxy(8) のための 3 つの強制的なアンカは、この
例から省略されます。ftp-proxy(8) マニュアルページを参照してください。
# NAT
# 発信パケットのソースアドレス (のどんなプロトコルも) を変換します.
# この場合、ゲートウェイの外部アドレスを除いて、すべてのアドレスが
# マップされます.
nat on $ext_if inet from ! ($ext_if) to any -> ($ext_if)
# NAT PROXYING
# 発信パケットのソースポートを任意のポートの代わりに割り当てられた
# プロキシポートにマップします.
# この場合、ゲートウェイ上のポート 500 で発信 isakmp をプロキシします.
nat on $ext_if inet proto udp from any port = isakmp to any -> ($ext_if) \
port 500
# BINAT
# 発信パケットのソースアドレス (のどんなプロトコルも) を変換します.
# 着信パケットの宛先アドレスを (双方向の) 内部のマシンに変換します.
binat on $ext_if from 10.1.2.150 to any -> $ext_if
# RDR
# 着信パケットの宛先アドレスを変換します.
例として、TCP と UDP ポートを内部のマシンにリダイレクトします。
rdr on $ext_if inet proto tcp from any to ($ext_if) port 8080 \
-> 10.1.2.151 port 22
rdr on $ext_if inet proto udp from any to ($ext_if) port 8080 \
-> 10.1.2.151 port 53
# RDR
# 発信 ftp 制御接続をポート 8021 で ftp-proxy(8) が実行するように
# プロキシするために localhost にそれらを送信するために変換します.
rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021
この例では、NAT ゲートウェイは、パブリックアドレス (192.0.2.16/28) のプー
ルを使用して内部のアドレスを変換するために、そして、内部のネットワークで
web サーバのグループに着信 web サーバ接続をリダイレクトするために、セット
アップされます。
# NAT LOAD BALANCE (ロードバランス)
# アドレスプールを使用して発信パケットのソースアドレスを変換します.
# 与えられたソースアドレスは、常にソースハッシュキーワードを使用して、
# 同じプールアドレスに変換されます.
nat on $ext_if inet from any to any -> 192.0.2.16/28 source-hash
# RDR ROUND ROBIN (ラウンドロビン)
# 着信 web サーバ接続を内部のネットワークで web サーバのグループに
# 変換します.
rdr on $ext_if proto tcp from any to any port 80 \
-> { 10.1.2.155, 10.1.2.160, 10.1.2.161 } round-robin
フィルタの例
# 外部のインタフェースは、kue0 です
# (157.161.48.183, 経路制御可能なアドレスのみ)
# と、NAT を行うための、プライベートネットワークは、10.0.0.0/8 です.
# 容易にそれを変更できるようにインタフェース名のためのマクロを使用します
ext_if = "kue0"
# すべての着信トラフィックを正常化
scrub in on $ext_if all fragment reassemble
# デフォルトですべてをブロックして、ログを記録する
block return log on $ext_if all
# 逆の経路制御がないソース (始点) から来るすべてをブロック
block in from no-route to any
# ingress インタフェースがルートバックのものと、それらのソースアドレスと
# マッチしないパケットをブロックします
block in from urpf-failed to any
# ソース (始点) としてアドレスがない発信パケットをブロックしログを記録し
# ます、良くしたく、ゴミを送信しないように、それらはなりすましされている
# か何か誤設定 (例えば、NAT を無効にした) されているかのいずれかです
block out log quick on $ext_if from ! 157.161.48.183 to any
# ブロードキャスト (同報通信) (ケーブルモデム雑音) を静かに落とします
block in quick on $ext_if from any to 255.255.255.255
# 予約されたアドレス空間と無効のアドレスからの着信パケットをブロックして
# ログに記録し、とにかくそれらを応答することができない
# (したがって、rst を返さない)、それらはなりすましされているか何か
# 誤設定されているかのいずれかです
block in log quick on $ext_if from { 10.0.0.0/8, 172.16.0.0/12, \
192.168.0.0/16, 255.255.255.255/32 } to any
# ICMP
# 特定の ICMP 問い合わせを out/in に通過させ、ホストアドレスと
# ICMP ID (タイプ/コードでない) で行われる状態 (ping) 状態を維持し、
# したがって、応答 (8/0 のための 0/0 のような) は、TCP/UDP 状態に
# よって操作される (常に TCP/UDP パケットを参照する) ICMP
# エラーメッセージ要求に一致します
pass on $ext_if inet proto icmp all icmp-type 8 code 0
# UDP
# すべての UDP 接続を外に通過し、状態を維持します
pass out on $ext_if proto udp all
# 特定の UDP 接続を内に通過し、状態を維持します (DNS)
pass in on $ext_if proto udp from any to any port domain
# TCP
# すべての TCP 接続を外に通過し、状態を調節します
pass out on $ext_if proto tcp all modulate state
# 特定の TCP 接続を内に通過し、状態を維持します (SSH, SMTP, DNS, IDENT)
pass in on $ext_if proto tcp from any to any port { ssh, smtp, domain, \
auth }
# それらは、通常ウイルスのワームであるので、Windows 9x SMTP 接続を許可
# しません. 代わりに、これらの OS をそれぞれ 1 つの接続に制限することも
# あり得ます.
block in on $ext_if proto tcp from any os {"Windows 95", "Windows 98"} \
to any port smtp
# IPv6
# すべての IPv6 トラフィックを in/out に通過します: 物理インタフェースと
# トンネルの両方で、2 つの異なった方法で、これを有効にしなければならない
# ことに注意してください
pass quick on gif0 inet6
pass quick on $ext_if proto ipv6
# パケットのタグ付け
# 3 つのインタフェースは: $int_if, $ext_if と $wifi_if (無線) です.
# NAT は、すべての発信パケットのために $ext_if で行われています.
# $int_if で内のパケットにタグ付けをし、$ext_if でそれらのタグ付け
# されたパケットを外に通過します. 他のすべての発信パケット (すなわち、
# 無線ネットワークからのパケット) がポート 80 にアクセスすることだけが
# 許可されます.
pass in on $int_if from any to any tag INTNET
pass in on $wifi_if from any to any
block out on $ext_if from any to any
pass out quick on $ext_if tagged INTNET
pass out on $ext_if proto tcp from any to any port 80
# それらが spamd(8) にリダイレクトされるとき、着信パケットにタグ付けし
# ます. パケットフィルタを通してそれらのパケットを通過するためにタグを
# 使用します.
rdr on $ext_if inet proto tcp from <spammers> to port smtp \
tag SPAMD -> 127.0.0.1 port spamd
block in on $ext_if
pass in on $ext_if inet proto tcp tagged SPAMD
文法
BNF 形式の pf.conf の構文は、次の通りです:
line = ( option | pf-rule | nat-rule | binat-rule | rdr-rule |
antispoof-rule | altq-rule | queue-rule | trans-anchors |
anchor-rule | anchor-close | load-anchor | table-rule |
include )
option = "set" ( [ "timeout" ( timeout | "{" timeout-list "}" ) ] |
[ "ruleset-optimization" [ "none" | "basic" | "profile" ]] |
[ "optimization" [ "default" | "normal" |
"high-latency" | "satellite" |
"aggressive" | "conservative" ] ]
[ "limit" ( limit-item | "{" limit-list "}" ) ] |
[ "loginterface" ( interface-name | "none" ) ] |
[ "block-policy" ( "drop" | "return" ) ] |
[ "state-policy" ( "if-bound" | "floating" ) ]
[ "state-defaults" state-opts ]
[ "require-order" ( "yes" | "no" ) ]
[ "fingerprints" filename ] |
[ "skip on" ifspec ] |
[ "debug" ( "none" | "urgent" | "misc" | "loud" ) ] )
pf-rule = action [ ( "in" | "out" ) ]
[ "log" [ "(" logopts ")"] ] [ "quick" ]
[ "on" ifspec ] [ route ] [ af ] [ protospec ]
hosts [ filteropt-list ]
logopts = logopt [ "," logopts ]
logopt = "all" | "user" | "to" interface-name
filteropt-list = filteropt-list filteropt | filteropt
filteropt = user | group | flags | icmp-type | icmp6-type | "tos" tos |
( "no" | "keep" | "modulate" | "synproxy" ) "state"
[ "(" state-opts ")" ] |
"fragment" | "no-df" | "min-ttl" number | "set-tos" tos |
"max-mss" number | "random-id" | "reassemble tcp" |
fragmentation | "allow-opts" |
"label" string | "tag" string | [ ! ] "tagged" string |
"set prio" ( number | "(" number [ [ "," ] number ] ")" ) |
"queue" ( string | "(" string [ [ "," ] string ] ")" ) |
"rtable" number | "probability" number"%" | "prio" number
nat-rule = [ "no" ] "nat" [ "pass" [ "log" [ "(" logopts ")" ] ] ]
[ "on" ifspec ] [ af ]
[ protospec ] hosts [ "tag" string ] [ "tagged" string ]
[ "->" ( redirhost | "{" redirhost-list "}" )
[ portspec ] [ pooltype ] [ "static-port" ] ]
binat-rule = [ "no" ] "binat" [ "pass" [ "log" [ "(" logopts ")" ] ] ]
[ "on" interface-name ] [ af ]
[ "proto" ( proto-name | proto-number ) ]
"from" address [ "/" mask-bits ] "to" ipspec
[ "tag" string ] [ "tagged" string ]
[ "->" address [ "/" mask-bits ] ]
rdr-rule = [ "no" ] "rdr" [ "pass" [ "log" [ "(" logopts ")" ] ] ]
[ "on" ifspec ] [ af ]
[ protospec ] hosts [ "tag" string ] [ "tagged" string ]
[ "->" ( redirhost | "{" redirhost-list "}" )
[ portspec ] [ pooltype ] ]
antispoof-rule = "antispoof" [ "log" ] [ "quick" ]
"for" ifspec [ af ] [ "label" string ]
table-rule = "table" "<" string ">" [ tableopts-list ]
tableopts-list = tableopts-list tableopts | tableopts
tableopts = "persist" | "const" | "counters" | "file" string |
"{" [ tableaddr-list ] "}"
tableaddr-list = tableaddr-list [ "," ] tableaddr-spec | tableaddr-spec
tableaddr-spec = [ "!" ] tableaddr [ "/" mask-bits ]
tableaddr = hostname | ifspec | "self" |
ipv4-dotted-quad | ipv6-coloned-hex
altq-rule = "altq on" interface-name queueopts-list
"queue" subqueue
queue-rule = "queue" string [ "on" interface-name ] queueopts-list
subqueue
anchor-rule = "anchor" [ string ] [ ( "in" | "out" ) ] [ "on" ifspec ]
[ af ] [ protospec ] [ hosts ] [ filteropt-list ] [ "{" ]
anchor-close = "}"
trans-anchors = ( "nat-anchor" | "rdr-anchor" | "binat-anchor" ) string
[ "on" ifspec ] [ af ] [ "proto" ] [ protospec ] [ hosts ]
load-anchor = "load anchor" string "from" filename
queueopts-list = queueopts-list queueopts | queueopts
queueopts = [ "bandwidth" bandwidth-spec ] |
[ "qlimit" number ] | [ "tbrsize" number ] |
[ "priority" number ] | [ schedulers ]
schedulers = ( cbq-def | priq-def | hfsc-def )
bandwidth-spec = "number" ( "b" | "Kb" | "Mb" | "Gb" | "%" )
action = "pass" | "block" [ return ] | [ "no" ] "scrub"
return = "drop" | "return" | "return-rst" [ "( ttl" number ")" ] |
"return-icmp" [ "(" icmpcode [ [ "," ] icmp6code ] ")" ] |
"return-icmp6" [ "(" icmp6code ")" ]
icmpcode = ( icmp-code-name | icmp-code-number )
icmp6code = ( icmp6-code-name | icmp6-code-number )
ifspec = ( [ "!" ] ( interface-name | interface-group ) ) |
"{" interface-list "}"
interface-list = [ "!" ] ( interface-name | interface-group )
[ [ "," ] interface-list ]
route = ( "route-to" | "reply-to" | "dup-to" )
( routehost | "{" routehost-list "}" )
[ pooltype ]
af = "inet" | "inet6"
protospec = "proto" ( proto-name | proto-number |
"{" proto-list "}" )
proto-list = ( proto-name | proto-number ) [ [ "," ] proto-list ]
hosts = "all" |
"from" ( "any" | "no-route" | "urpf-failed" | "self" | host |
"{" host-list "}" ) [ port ] [ os ]
"to" ( "any" | "no-route" | "self" | host |
"{" host-list "}" ) [ port ]
ipspec = "any" | host | "{" host-list "}"
host = [ "!" ] ( address [ "/" mask-bits ] | "<" string ">" )
redirhost = address [ "/" mask-bits ]
routehost = "(" interface-name [ address [ "/" mask-bits ] ] ")"
address = ( interface-name | interface-group |
"(" ( interface-name | interface-group ) ")" |
hostname | ipv4-dotted-quad | ipv6-coloned-hex )
host-list = host [ [ "," ] host-list ]
redirhost-list = redirhost [ [ "," ] redirhost-list ]
routehost-list = routehost [ [ "," ] routehost-list ]
port = "port" ( unary-op | binary-op | "{" op-list "}" )
portspec = "port" ( number | name ) [ ":" ( "*" | number | name ) ]
os = "os" ( os-name | "{" os-list "}" )
user = "user" ( unary-op | binary-op | "{" op-list "}" )
group = "group" ( unary-op | binary-op | "{" op-list "}" )
unary-op = [ "=" | "!=" | "<" | "<=" | ">" | ">=" ]
( name | number )
binary-op = number ( "<>" | "><" | ":" ) number
op-list = ( unary-op | binary-op ) [ [ "," ] op-list ]
os-name = operating-system-name
os-list = os-name [ [ "," ] os-list ]
flags = "flags" ( [ flag-set ] "/" flag-set | "any" )
flag-set = [ "F" ] [ "S" ] [ "R" ] [ "P" ] [ "A" ] [ "U" ] [ "E" ]
[ "W" ]
icmp-type = "icmp-type" ( icmp-type-code | "{" icmp-list "}" )
icmp6-type = "icmp6-type" ( icmp-type-code | "{" icmp-list "}" )
icmp-type-code = ( icmp-type-name | icmp-type-number )
[ "code" ( icmp-code-name | icmp-code-number ) ]
icmp-list = icmp-type-code [ [ "," ] icmp-list ]
tos = ( "lowdelay" | "throughput" | "reliability" |
[ "0x" ] number )
state-opts = state-opt [ [ "," ] state-opts ]
state-opt = ( "max" number | "no-sync" | timeout | "sloppy" |
"source-track" [ ( "rule" | "global" ) ] |
"max-src-nodes" number | "max-src-states" number |
"max-src-conn" number |
"max-src-conn-rate" number "/" number |
"overload" "<" string ">" [ "flush" ] |
"if-bound" | "floating" )
fragmentation = [ "fragment reassemble" ]
timeout-list = timeout [ [ "," ] timeout-list ]
timeout = ( "tcp.first" | "tcp.opening" | "tcp.established" |
"tcp.closing" | "tcp.finwait" | "tcp.closed" |
"udp.first" | "udp.single" | "udp.multiple" |
"icmp.first" | "icmp.error" |
"other.first" | "other.single" | "other.multiple" |
"frag" | "interval" | "src.track" |
"adaptive.start" | "adaptive.end" ) number
limit-list = limit-item [ [ "," ] limit-list ]
limit-item = ( "states" | "frags" | "src-nodes" ) number
pooltype = ( "bitmask" | "random" |
"source-hash" [ ( hex-key | string-key ) ] |
"round-robin" ) [ sticky-address ]
subqueue = string | "{" queue-list "}"
queue-list = string [ [ "," ] string ]
cbq-def = "cbq" [ "(" cbq-opt [ [ "," ] cbq-opt ] ")" ]
priq-def = "priq" [ "(" priq-opt [ [ "," ] priq-opt ] ")" ]
hfsc-def = "hfsc" [ "(" hfsc-opt [ [ "," ] hfsc-opt ] ")" ]
cbq-opt = ( "default" | "borrow" | "red" | "ecn" | "rio" )
priq-opt = ( "default" | "red" | "ecn" | "rio" )
hfsc-opt = ( "default" | "red" | "ecn" | "rio" |
linkshare-sc | realtime-sc | upperlimit-sc )
linkshare-sc = "linkshare" sc-spec
realtime-sc = "realtime" sc-spec
upperlimit-sc = "upperlimit" sc-spec
sc-spec = ( bandwidth-spec |
"(" bandwidth-spec number bandwidth-spec ")" )
include = "include" filename
関連ファイル
/etc/hosts ホスト名データベース。
/etc/pf.conf ルールセットファイルのデフォルトの位置。ファイルは、それ
が標準のインストールでインストールされないように手動で作
成されなければなりません。
/etc/pf.os OS 指紋のデフォルトの位置。
/etc/protocols プロトコル名データベース。
/etc/services サービス名データベース。
関連項目
altq(4), carp(4), icmp(4), icmp6(4), ip(4), ip6(4), pf(4), pfsync(4),
tcp(4), udp(4), hosts(5), pf.os(5), protocols(5), services(5), ftp-
proxy(8), pfctl(8), pflogd(8)
歴史
pf.conf ファイル形式は、OpenBSD 3.0 ではじめて登場しました。
FreeBSD 12.2 March 10, 2019 FreeBSD 12.2