日本語 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
AUTHPF(8) FreeBSD システム管理者マニュアル AUTHPF(8)
名称
authpf, authpf-noip -- ゲートウェイユーザシェルの認証
書式
authpf
authpf-noip
解説
authpf は、ゲートウェイを認証するためのユーザシェルです。それは、ユーザが
sshd(8) でセッションを認証して、開始するとき、pf(4) 規則を変更するために
使用され、ユーザのセッションが終了するとき、これらの変更は、元に戻されま
す。典型的な使用として、それらにインターネットの使用を許す前にユーザを認
証するゲートウェイ、または異なった場所に異なったユーザを許可するゲート
ウェイがあります。フィルタ規則と安全スイッチを適切に設定する組み合わせ
で、ユーザがそれらのネットワークトラフィックに責任を取ることを保証するた
めに authpf を使用することができます。それは、ssh(1) だけを通して接続する
ことができるユーザと共に使用されることになっており、有効にされる /dev/fd
でマウントされた pf(4) サブシステムと fdescfs(5) ファイルシステムを要求し
ます。
authpf-noip は、複数の接続が同じ IP アドレスから行うことができるユーザ
シェルです。接続がゲートウェイシステムを通してトンネル化され、直接ユーザ
名に関連づけることができる場合に、主として役に立ちます。IP アドレスによっ
て接続を分類するとき、説明責任を確実にすることができません。この場合、ク
ライアントの IP アドレスは、client_ip マクロまたは authpf_users テーブル
を通してパケットフィルタに提供されません。さらに、クライアント IP アドレ
スに関連している状態は、セッションが終わるとき、消去されません。
authpf または authpf-noip のいずれかを使用するために、ユーザのシェルは、
/usr/sbin/authpf または /usr/sbin/authpf-noip に設定される必要がありま
す。
authpf は、ユーザが、アクティブな ssh(1) セッションを維持し、syslogd(8)
へのセッションの成功した開始と終わりをログ記録する限り、個々のユーザまた
はクライアント IP アドレスのためのフィルタと変換規則を変更するために
pf.conf(5) 構文を使用します。authpf は、SSH_CLIENT 環境変数を通してクライ
アントの接続 IP アドレスを検索し、追加アクセスチェックを実行した後に、ど
のようなフィルタと変換規則 (もしあるならば) が追加されるかを決定するため
にテンプレートファイルを読み込み、authpf_users テーブルで接続されたユーザ
の IP アドレスのリストを維持します。セッションの終了時では、始動で追加さ
れたのと同じ規則とテーブルエントリを取り除き、クライアントの IP アドレス
に関連しているすべての状態を消去します。
それぞれの authpf プロセスは、別々のルールセットの規則をすべての authpf
プロセスによって共有された pf(4) anchor 内に格納します。デフォルトで、
anchor 名の "authpf" が使用され、そして、ルールセット名は、"user
name(pid)" として authpf プロセスのユーザ名と PID と等しくなります。次の
規則は、任意の authpf 規則の評価を引き起こすために主なルールセット
/etc/pf.conf に追加される必要があります:
nat-anchor "authpf/*"
rdr-anchor "authpf/*"
binat-anchor "authpf/*"
anchor "authpf/*"
アンカ名の終わりの "/*" は、authpf によってアンカにアタッチされたルール
セットを処理するために pf(4) が必要となります。
フィルタと変換規則
authpf のためのフィルタと変換規則は、pf.conf(5) で記述される同じ形式を使
用します。唯一の違いは、これらの規則が、authpf が実行されるときはいつも、
接続 IP アドレスが割り当てられる、マクロ user_ip を使用する (たぶん、する
べきである) ことです。さらに、マクロ user_id は、ユーザ名に割り当てられま
す。
フィルタと変換規則は、authpf.rules と呼ばれるファイルに格納されます。この
ファイルは、最初に、/etc/authpf/users/$USER/ で、そして次に、/etc/authpf/
で検索されます。両方が存在しているなら、これらのファイルの 1 つだけが使用
されます。
/etc/authpf/users/$USER/ ディレクトリからのユーザ毎の規則は、デフォルトで
ない規則が個々ユーザ基盤で必要であるときに、使用されることを目的としてい
ます。ユーザがこれらの設定ファイルを書き込むか変更することができないこと
を保証することは、重要です。
authpf.rules ファイルは、authpf が実行する上の位置の 1 つに存在しなければ
なりません。
設定
オプションは、/etc/authpf/authpf.conf ファイルによって制御されます。ファ
イルが空であるなら、デフォルトは、すべての設定オプションに使用されます。
ファイルは、1 行毎に name=value 形式のペアから成ります。現在、許されてい
る値は、次の通りです:
anchor=name
"authpf" の代わりに指定された anchor 名を使用します。
table=name
"authpf_users" の代わりに指定された table 名を使用します。
ユーザメッセージ
呼び出しが成功すれば、authpf は、その人が認証されたとユーザに告げるメッ
セージを表示します。さらに、ファイルが存在していて、読み込み可能であるな
ら、ファイル /etc/authpf/authpf.message の内容を表示します。
authpf によって提供された制御に追加の精度を提供するための 2 つの方法が存
在しています - ssh(1) で認証されるユーザを明らかに許され、わずかの厄介な
個人に対するアクセスのみを拒否して、ゲートウェイを設定することは可能で
す。これは、/etc/authpf/banned/ のファイル名として禁止されたユーザのログ
イン名でファイルを作成することによって、行われます。このファイルの内容
は、禁止されたユーザに表示され、その結果、それらがそれらのサービスを復元
したいなら、それらが禁止されて、それらが行くことができる場所、どのように
そこに到着するかを、ユーザに知らせるための方法を提供します。これは、デ
フォルトの振る舞いです。
また、特定のユーザアクセスをのみを許すように authpf を設定することも可能
です。これは、/etc/authpf/authpf.allow の 1 行毎に 1 つの、それらのログイ
ン名をリストすることによって行われます。また、グループ名の先頭に "%" を追
加することによって、ユーザのグループを示すことができ、ログインクラス名の
先頭に "@" を追加することによって、すべてのログインクラスのメンバを示すこ
とができます。"*" が行で見つけられるなら、すべてのユーザ名が適合します。
authpf がゲートウェイを使用するユーザのパーミッションを検証することができ
ないなら、簡潔なメッセージを印刷 (表示) して、死にます。禁止は、許可のす
べてに優先することを注意されるべきです。
失敗すれば、メッセージは、システム管理者のために syslogd(8) にログ記録さ
れます。ユーザは、これらを見ませんが、システムは、技術的困難のために利用
可能でないと告げます。また、ファイルが存在していて、読み込み可能であるな
ら、ファイル /etc/authpf/authpf.problem の内容を表示します。
設定問題
authpf は、ユーザがアクティブなセッションを維持する限り、変更されたフィル
タ規則を維持します。しかしながら、このセッションの存在は、ユーザが認証さ
れることを意味することを覚えておくことは重要です。このため、セッションの
セキュリティを確実にするために sshd(8) を設定して、ユーザが接続するネット
ワークが安全であることを確実にすることは重要です。sshd(8) は、反応しない
ようになるなら、または arp かアドレス偽造がセッションをハイジャックするた
めに使用されるなら、ssh セッションがすぐに終了されることを保証するために
ClientAliveInterval と ClientAliveCountMax パラメータを使用するように設定
されるべきです。TCP キープアライブ (生き続ける) は、それらが安全でないの
で、このためには、十分でないことに注意してください。また、
AllowTcpForwarding と PermitTunnel のような、様々な SSH トンネルメカニズ
ムは、パケットフィルタのルールセットによって強制された制限を回避すること
からそれらを防ぐために authpf ユーザのために無効にされるべきであることに
注意してください。
authpf は、ユーザのセッションの間に作成された状態テーブルエントリを取り除
きます。これは、制御 ssh(1) セッションがクローズされた後に渡すことができ
る認証されないトラフィックがないことを確実にします。
authpf は、通常、マシンを使用する普通 (非管理の) のユーザがいないゲート
ウェイマシンのために設計されます。管理者は、authpf が、通常のユーザによっ
て (設定ファイルの内容に基づいている) フィルタ規則を変更するために使用さ
れるかどうかのような、それが実行される環境を通してフィルタ規則を変更する
ために使用することができることを覚えていなければなりません。ユーザのシェ
ルとして authpf が使えるユーザと同様に、マシンにそれを使用する通常のユー
ザある場合には、通常のユーザが /etc/authpf/authpf.allow または
/etc/authpf/banned/ 機能を使用することによって authpf を実行することを防
ぐべきです。
authpf は、パケットフィルタとアドレス変換規則を変更します、これために、そ
れは、慎重に設定される必要があります。/etc/authpf/authpf.conf authpf は、
/etc/authpf/authpf.conf ファイルが存在していないなら、実行されないで、静
かに終了します。authpf が主なパケットフィルタ規則に持っている効果を考慮し
た後に、システム管理者は、適切な /etc/authpf/authpf.conf ファイルを作成す
ることによって、authpf を有効にすることができます。
使用例
制御ファイル - ユーザ特有のアクセス制御機構を説明するために、ボブという典
型的なユーザを考えましょう。通常、ボブが彼自身を認証することができる限
り、authpf プログラムは、適切な規則をロードします。/etc/authpf/banned/
ディレクトリに入ります。ボブが、どうゆわけか時の権力者の見地から信用を
失ったなら、それらは、彼がネットワークを使用することを禁止された理由に関
するメッセージを含むファイル /etc/authpf/banned/bob を作成することによっ
てゲートウェイを使用することから彼を禁じることができます。ボブがいったん
適当な苦行を課せられると、彼のアクセスは、ファイル /etc/authpf/banned/bob
を移動するか、または削除することによって、復元されるかもしれません。
今度は、アリス、ボブ、キャロル、とデイブを含むワークグループを考えます。
彼らには、無許可の使用から保護したい無線ネットワークがあります。これを達
成するために、彼らは、(1 行毎に 1 つ) "%" を先頭に追加した彼らのログイン
ID、グループ、または "@" を先頭に追加したログインのクラスをリストしたファ
イル /etc/authpf/authpf.allow を作成します。この時点では、イブが sshd(8)
で認証することができるとしても、彼女は、ゲートウェイを使用することができ
ないでしょう。ワークグループにユーザを加えたり削除することは、許容ユーザ
ID のリストを維持する簡単な事柄です。ボブが時の権力者をもう一度困らせるな
ら、彼らは、普通の /etc/authpf/banned/bob ファイルを作成することによって
ゲートウェイを彼が使用することを禁止することができます。ボブが許容ファイ
ルにリストされるけれども、彼は、禁止ファイルの存在のために、このゲート
ウェイを使用することを止められます。
配布された認証 - sync で多くのローカルパスワードファイルを保存することを
sysadmin に強制するよりもむしろ配布されたパスワードシステムとインタフェー
スをとることはしばしば望ましいことです。OpenBSD の login.conf(5) メカニズ
ムは、正当なシェルをフォーク (fork) するために使用することができます。そ
れを起こらせるために、login.conf(5) には、次ようなエントリがあるべきです:
shell-default:shell=/bin/csh
default:\
...
:shell=/usr/sbin/authpf
daemon:\
...
:shell=/bin/csh:\
:tc=default:
staff:\
...
:shell=/bin/csh:\
:tc=default:
デフォルトパスワードファイルを使用して、すべてのユーザは、/bin/csh を取得
するルート以外の彼らのシェルとして authpf を取得します。
SSH 設定 - 前述のように、sshd(8) は、ネットワーク攻撃を検出して、打ち倒す
ために適切に設定されなければなりません。そのためには、次のオプションが
sshd_config(5) に加えられるべきです:
Protocol 2
ClientAliveInterval 15
ClientAliveCountMax 3
これは、ハイジャック犯が ssh キープアライブメッセージを偽造することができ
ないはずであるので、反応がないか偽造しているセッションが 1 分以内に終了す
ることを確実にします。
バナー - いったん認証されると、/etc/authpf/authpf.message の内容がユーザ
に示されます。このメッセージは、適切な使用ポリシのスクリーンいっぱいの表
示、/etc/motd の内容か、または次と同じくらい簡単なものであるかもしれませ
ん:
This means you will be held accountable by the powers that be
for traffic originating from your machine, so please play nice.
<訳>
これは、あなたのマシンから起こるトラフィックに関して権限によって
あなたに責任があることを意味するので、悪さをしないでください。
システムが壊れているとき、ユーザが行くべき所を告げるために、
/etc/authpf/authpf.problem は、何か次のようなものを含むことができます:
Sorry, there appears to be some system problem. To report this
problem so we can fix it, please phone 1-900-314-1597 or send
an email to remove@bulkmailerz.net.
<訳>
すみません、何らかのシステムの問題があるようです。私たちがそれを
修理できるように、この問題を報告するには、1-900-314-1597 に電話
するか、または remove@bulkmailerz.net にメールを送ってください。
パケットフィルタ規則 - このゲートウェイが (数 100 のポートがあるハブ) 無
線ネットワークを保護するために使用される領域では、ユーザ毎の規則と同様に
デフォルトのルールセットは、ssh(1), ssl(8) または ipsec(4) のような暗号化
されたプロトコルを越えて、たぶんほとんどのものを許すべきではありません。
安全な交換ネットワークでは、認証アカウントが与えられた訪問者のためのプラ
グインが盗まれた状態で、利用者は、すべてを出すことを許したいかもしれませ
ん。このような状況において、安全な交換は、アドレステーブルオーバフロー攻
撃を防ごうとするものです。
/etc/pf.conf の例:
# デフォルトで、内部のクライアントが ssh を使用して話すことが
# できるようにし、dns サーバを使用できるようにします。
internal_if="fxp1"
gateway_addr="10.0.1.1"
nat-anchor "authpf/*"
rdr-anchor "authpf/*"
binat-anchor "authpf/*"
block in on $internal_if from any to any
pass in quick on $internal_if proto tcp from any to $gateway_addr \
port = ssh
pass in quick on $internal_if proto udp from any to $gateway_addr \
port = domain
anchor "authpf/*"
交換された有線ネットのために - この例の /etc/authpf/authpf.rules は、なに
も実際の制限を行いません。IP アドレスをオンとオフに切替えて、TCP 接続をロ
グ記録します。
external_if = "xl0"
internal_if = "fxp0"
pass in log quick on $internal_if proto tcp from $user_ip to any
pass in quick on $internal_if from $user_ip to any
無線または共有されたネットのために - この例の /etc/authpf/authpf.rules
は、私たちがもう少し制限する必要があるかもしれない (パブリックな無線ネッ
トワークのような) 不安定なネットワークのために使用することができます。
internal_if="fxp1"
ipsec_gw="10.2.3.4"
# ftp-proxy(8) によってプロキシするための rdr ftp
rdr on $internal_if proto tcp from $user_ip to any port 21 \
-> 127.0.0.1 port 8021
# ftp, ssh, www と https だけ出ることを許して、ユーザに ipsec サーバで
# ipsec にネゴシエートすることを許します。
pass in log quick on $internal_if proto tcp from $user_ip to any \
port { 21, 22, 80, 443 }
pass in quick on $internal_if proto tcp from $user_ip to any \
port { 21, 22, 80, 443 }
pass in quick proto udp from $user_ip to $ipsec_gw port = isakmp
pass in quick proto esp from $user_ip to $ipsec_gw
NAT の処理 - 次の /etc/authpf/authpf.rules は、タグを使用して、どのように
NAT を処理するかを示します:
ext_if = "fxp1"
ext_addr = 129.128.11.10
int_if = "fxp0"
# nat とタグ接続...
nat on $ext_if from $user_ip to any tag $user_ip -> $ext_addr
pass in quick on $int_if from $user_ip to any
pass out log quick on $ext_if tagged $user_ip
authpf によって追加された上記の規則で、それぞれのユーザの NAT された接続
のための外向きの接続は、ユーザがルールセット名から識別される、次の例のよ
うにログ記録されます。
# tcpdump -n -e -ttt -i pflog0
Oct 31 19:42:30.296553 rule 0.bbeck(20267).1/0(match): pass out on fxp1: \
129.128.11.10.60539 > 198.137.240.92.22: S 2131494121:2131494121(0) win \
16384 <mss 1460,nop,nop,sackOK> (DF)
authpf_users table を使用して - 単純な authpf の設定は、"authpf_users"
table を使用することによって、アンカなし実装することができます。例えば、
次の pf.conf(5) 行は、ログインされたユーザに対するアクセスを SMTP と IMAP
に与えます:
table <authpf_users> persist
pass in on $ext_if proto tcp from <authpf_users> \
to port { smtp imap }
また、アンカと組み合わせて "authpf_users" table を使用することも可能で
す。例えば、pf(4) 処理は、ログインされたユーザから来るパケットのためだけ
にアンカを検索することによって、スピードアップすることができます:
table <authpf_users> persist
anchor "authpf/*" from <authpf_users>
rdr-anchor "authpf/*" from <authpf_users>
トンネル化されたユーザ - 通常、authpf は、クライアント IP アドレス毎に 1
つのセッションだけを許可します。しかしながら、接続が ssh(1) または
ipsec(4) を通してトンネル化されたときのようないくつかの場合に、クライアン
ト IP アドレスの代わりにユーザのユーザ ID に基づいて接続を許可することが
できます。この場合、NAT ゲートウェイの後ろの複数のユーザが接続できるよう
に authpf-noip 使用することは、適切です。以下の /etc/authpf/authpf.rules
の例で、リモートユーザは、リモートのデスクトップセッションにそれらのワー
クステーションをトンネル化することができます:
internal_if="bge0"
workstation_ip="10.2.3.4"
pass out on $internal_if from (self) to $workstation_ip port 3389 \
user $user_id
関連ファイル
/etc/authpf/authpf.conf
/etc/authpf/authpf.allow
/etc/authpf/authpf.rules
/etc/authpf/authpf.message
/etc/authpf/authpf.problem
関連項目
pf(4), fdescfs(5), pf.conf(5), securelevel(7), ftp-proxy(8)
歴史
authpf プログラムは、OpenBSD 3.1 ではじめて登場しました。
バグ
設定問題は、トリッキです。認証している ssh(1) 接続は、安全かもしれません
が、ネットワークが安全でないなら、ユーザは、同じネットワークで攻撃者に安
全でないプロトコルをあらわにするか、または、IP アドレスを偽造することに
よって、ユーザとなるように見せかけるためにネットワークで他の攻撃者を可能
とするかもしれません。
authpf は、ユーザが他のユーザへのサービスを否定することを防ぐように設計さ
れていません。
FreeBSD 12.2 January 29 2014 FreeBSD 12.2