AUTHPF(8)

FreeBSD System Manager's Manual

AUTHPF(8)

名称

authpf, authpf-noip — ゲートウェイユーザシェルの認証

書式

authpf

authpf-noip

解説

authpf は、ゲートウェイを認証するためのユーザシェルです。それは、ユーザが sshd(8) でセッションを認証して、開始するとき、 pf(4) 規則を変更するために使用され、ユーザのセッションが終了するとき、これらの変更は、元に戻されます。典型的な使用として、それらにインターネットの使用を許す前にユーザを認証するゲートウェイ、または異なった場所に異なったユーザを許可するゲートウェイがあります。フィルタ規則と安全スイッチを適切に設定する組み合わせで、ユーザがそれらのネットワークトラフィックに責任を取ることを保証するために authpf を使用することができます。 ssh(1) だけを通して接続できて、 pf(4) サブシステムが有効にされることを必要とする、ユーザと共に使用されることになっています。

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"が使用され、そして、ルールセット名は、 "username(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 形式のペアから成ります。現在、許されている値は、次の通りです:

ユーザメッセージ

呼び出しが成功すれば、 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

歴史

authpf プログラムは、 OpenBSD 3.1 ではじめて登場しました。

バグ

設定問題は、トリッキです。認証している ssh(1) 接続は、安全かもしれませんが、ネットワークが安全でないなら、ユーザは、同じネットワークで攻撃者に安全でないプロトコルをあらわにするか、または、IP アドレスを偽造することによって、ユーザとなるように見せかけるためにネットワークで他の攻撃者を可能とするかもしれません。

authpf は、ユーザが他のユーザへのサービスを否定することを防ぐように設計されていません。

January 6, 2009

FreeBSD

YOS OPENSONAR

名称

書式

解説

フィルタと変換規則

設定

ユーザメッセージ

設定問題

使用例

関連ファイル

関連項目

歴史

バグ