os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Catching up to 3.1-19990210-BETA. (again)

Browse source 
Reviewed by:	Japanese Online Manual Project <man-jp@jp.FreeBSD.ORG>
Submitted by:	Kazuo Horikawa <k-horik@yk.rim.or.jp>
This commit is contained in:
Jun Kuriyama 1999-02-12 13:42:53 +00:00
parent b9501c2b3b
commit c8496e4b91
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=4293
8 changed files with 1330 additions and 944 deletions

151
ja/man/man5/isdnd.rc.5
View file

@ -23,7 +23,7 @@
.\" SUCH DAMAGE.
.\"
.\" %Id: isdnd.rc.5,v 1.1 1998/12/27 21:47:01 phk Exp %
.\" jpman %Id: isdnd.rc.5,v 1.2 1999/01/24 06:59:47 horikawa Chk %
.\" jpman %Id: isdnd.rc.5,v 1.4 1999/02/11 15:43:12 horikawa Stab %
.\"
.\" last edit-date: [Sat Dec 5 18:10:08 1998]
.\"
@ -44,7 +44,7 @@ ISDN
.Pp
設定ファイルには、第 1 桁から始まるキーワードが複数含まれます。
キーワードの後には、1 個以上の空白・タブ、単一の等号、1 個以上の空白・タブ、
キーワード依存のパラメータ値が続きます。
キーワード依存のパラメータ値と続きます。
.Pp
文字 '#' で開始する行はコメント行として扱われます。
.Pp
@ -175,9 +175,9 @@ ISDN
.It Li regexpr
本キーワードは、正規表現を指定するために使用されます。
1 度より多く指定することが可能であり、
コンパイル時に依存する値まで指定可能です
(現在、ソースにおける MAX_RE の定義により、5 に設定されます)。
1 度以上、コンパイル時依存の回数
(現在、ソースにおける MAX_RE の定義では 5 回)
まで指定することが可能です。
.Pp
指定した全正規表現は実行時にログ文字列と比較され、
マッチした場合には、ログテキストをパラメータとしてプログラムが実行されます
@ -209,7 +209,7 @@ ISDN
.It Li rtprio
.Nm isdnd
が実行されるリアルタイム優先度を、整数値範囲 0 ～ 31 で指定します。
が実行されるリアルタイム優先度を、0 ～ 31 の範囲の整数値で指定します。
0 は最高の優先度です。
本キーワードは省略可能です。
指定しない場合、
@ -237,7 +237,7 @@ ISDN
.Bl -tag -width unitlengthsrc -compact
.It Li answerprog
本キーワードは、内向き電話接続が設定エントリにおいて
本キーワードは、着信電話接続が設定エントリにおいて
.Em answer
を指定した場合に実行される、プログラムの名前を指定するために使用されます。
デフォルト名は
@ -251,11 +251,11 @@ ISDN
(省略可能)
.It Li alert
呼び出しを受け付ける前に待つ秒数を指定するために使用します。
本キーワードは、内向き電話呼び出し (dialin-reaction = answer)
呼 (call) を受け付ける前に待つ秒数を指定するために使用します。
本キーワードは、電話着呼 (dialin-reaction = answer)
のためにのみ指定可能です。
応答マシンが実行を開始する前に、
電話の内向き呼び出しを受け付ける機会を持つために、使用します。
留守番マシンが実行を開始する前に、
電話の着呼 (incoming call) を受け付ける機会を持つために使用します。
本パラメータの最小値は 5 秒であり、パラメータの最大値は 180 秒です。
(省略可能)
@ -272,30 +272,30 @@ HDLC
.El
.It Li callbackwait
リモートサイトからの呼び出しをハングアップしてから
リモートサイトからの呼を切ってから
リモートサイトにコールバックするまでに待つ秒数です。(省略可能)
.It Li calledbackwait
ローカルサイトからリモートサイトを呼び出してから
ローカルサイトがリモートサイトを呼び出した後、
リモートサイトがローカルサイトにコールバックするまでに待つ秒数です。(省略可能)
.It Li dialin-reaction
内向きの接続要求を受け付けた場合にどうするかを指定するために使用します。
着信接続要求を受けた場合にどうするかを指定するために使用します。
本キーワードは必須です。
現在サポートされているパラメータは次の通りです:
.Pp
.Bl -tag -width calledback -compact -offset
.It Ar accept
内向き呼び出しを受け付けます。
着呼を受け付けます。
.It Ar reject
内向き呼び出しを拒否します。
着呼を拒否します。
.It Ar ignore
内向き呼び出しを無視します。
着呼を無視します。
.It Ar answer
内向き音声呼び出しに対して、電話応答を開始します。
着信音声呼び出しに対して、留守番電話を開始します。
.It Ar callback
リモートサイトが呼び出したとき、
ハングアップしてリモートサイトにコールバックします。
その呼を切ってリモートサイトにコールバックします。
.El
.It Li dialout-type
@ -305,10 +305,10 @@ HDLC
.Pp
.Bl -tag -width Ds -compact -offset
.It Ar normal
通常動作。呼び出しを受け付けると思われるリモートサイトを呼び出します。
通常動作。呼を受け付けると思われるリモートサイトを呼び出します。
.It Ar calledback
コールバック動作。
呼び出しを拒否してから当方にコールバックするリモートサイトを呼び出します。
呼を拒否してから当方にコールバックするリモートサイトを呼び出します。
.El
.It Li dialrandincr
@ -321,10 +321,10 @@ HDLC
最小化します。
.It Li dialretries
ダイヤルを諦める前に再試行する回数です。(省略可能)
ダイヤルをあきらめる前に再試行する回数です。(省略可能)
.It Li direction
本キーワードは、内外向き・内向きのみ・外向きのみのいずれの接続が可能であるかを
本キーワードは、発信着信・発信のみ・着信のみのいずれの接続が可能であるかを
設定するために使用します。
本キーワードは省略可能であり、デフォルトは
.Em inout
@ -336,14 +336,14 @@ HDLC
.It Ar inout
通常動作。接続の確立は、リモートからでもローカルからでも可能です。
.It Ar in
内向き接続のみ可能です。
着信接続のみ可能です。
.It Ar out
外向き接続のみ可能です。
発信接続のみ可能です。
.El
.It Li downtries
失敗する試行回数を指定するために使用します。
失敗する試行 (=再試行サイクルです!) をこの回数だけ行った後、
試行 (=再試行サイクルです!) がこの回数だけ失敗すると、
インタフェースを (
.Em downtime
秒だけ) 無効にします。
@ -355,39 +355,40 @@ HDLC
.Em downtries
の設定値の回数の後、
インタフェースが無効化される秒数を設定するために使用されます。
(前述のキーワード
(詳細はキーワード
.Em usedown
も参照)。
を参照)。
本キーワードは省略可能であり、デフォルトで 60 秒に設定されます。
.It Li earlyhangup
次の課金単位となる前にハングアップさせるための (保険の) 秒数を指定します。
次の課金単位となる前に接続を切るための (保険の) 秒数を指定します。
(省略可能)
.It Li idletime-outgoing
ハングアップ前に外向き接続がアイドルとなる秒数。(省略可能)
接続を切る前に発呼 (outgoing call) がアイドルとなる秒数。(省略可能)
.It Li idletime-incoming
ハングアップ前に内向き接続がアイドルとなる秒数。(省略可能)
接続を切る前に着呼がアイドルとなる秒数。(省略可能)
.It Li isdncontroller
本エントリの接続に対して使用される ISDN 制御番号。(必須)
本エントリの接続に使用される ISDN コントローラ番号。(必須)
.It Li isdnchannel
本エントリの接続に対して使用される ISDN 制御チャネル番号。
ここで明示的にチャネルを選択すると SETUP メッセージは本チャネルを要求しますが、
本エントリの接続に対して使用される ISDN コントローラチャネル番号。
ここで明示的にチャネルを選択すると
SETUP メッセージはそのチャネルを要求しますが、
リクエストに
.Em 好ましい
(本チャネルを好む) とマークするだけであって、
排他的 (本チャネルのみ受け付けることを意味する) とマークするのではありません。
.Em 望ましい (preferred)
(指定チャネルを望む) とマークするだけであって、
排他的 (指定チャネルのみ受け付ける) とマークするのではありません。
よって、交換局は要求されたチャネル以外を選択することが依然として可能です!
(必須)
.It Li isdntxdel-incoming
.Em timeout()
カーネルサブルーチンに適合する遅延値であり、
.Em 内向き
ISDN 接続に対して接続が成功裏に確立した後に、
.Em 着信
ISDN 接続に対して接続確立が成功した後に、
最初のパケットの送出をこの値だけ遅延させます。
指定単位は 1/100 秒です。
ゼロ (0) を指定すると本機能を無効化します。これがデフォルト値です。
@ -399,14 +400,14 @@ IP over raw HDLC ISDN
.It Li isdntxdel-outgoing
.Em timeout()
カーネルサブルーチンに適合する遅延値であり、
.Em 外向き
ISDN 接続に対して接続が成功裏に確立した後に、
.Em 発信
ISDN 接続に対して接続確立が成功した後に、
最初のパケットの送出をこの値だけ遅延させます。
指定単位は 1/100 秒です。
ゼロ (0) を指定すると本機能を無効化します。これがデフォルト値です。
本機能は
.Xr i4bipr 4
IP over raw HDLC ISDN 用に実装されました
IP over raw HDLC ISDN ドライバ用に実装されました
(本ドライバに対してのみ意味を持ちます)。(省略可能)
.It Li local-phone-dialout
@ -416,12 +417,12 @@ IP over raw HDLC ISDN
.Em "発番号情報要素 (Calling Party Number Information Element)"
に埋め込まれます。
.Pp
本キーワードは、ipr ユーザランドインタフェース用のために必須です。
本キーワードは、ipr ユーザランドインタフェースのために必須です。
.\" 原文の .em (Execute Macro) は、引数無しの場合効果が無いので削除
.\" horikawa@jp.freebsd.org 1999/01/19
.It Li local-phone-incoming
内向き呼び出しの宛先を確認するために使用する、ローカルの電話番号です。
着呼の宛先を確認するために使用する、ローカルの電話番号です。
リモートサイトがダイヤルインするとき、
リモートサイトの希望接続先がローカルサイトであることを確認するために、
本番号を使用します。
@ -432,9 +433,9 @@ IP over raw HDLC ISDN
本キーワードは ipr インタフェースのために必須です。
.It Li name
本設定エントリにシンボルによる名前を定義します。
その設定エントリにシンボルによる名前を定義します。
全画面表示においてこの名前を使用して
リモートサイトへのリンクを識別し易くすることと、
リモートサイトへのリンクを識別しやすくすることと、
アカウンティングに使用することを目的としています。(必須)
.It Li ratetype
@ -443,24 +444,24 @@ IP over raw HDLC ISDN
例えば、
ratetype=0 は /etc/isdn/isdnd.rates 中で "ra0" で開始する行を選択します
(典型的には ra0 行は、
各曜日および各時刻における、ローカル呼び出し料金の表集合です。)
各曜日および各時刻における、ローカルの呼び出し料金の表集合です。)
.It Li recoverytime
ダイヤル再試行とダイヤル再試行の間に待つ秒数。(省略可能)
.It Li remdial-handling
複数個の外向き番号が指定された場合のダイヤルアウト動作を指定するために
複数個の発信番号が指定された場合のダイヤルアウト動作を指定するために
使用されます。
現在サポートされているパラメータは次の通りです:
.Pp
.Bl -tag -width Ds -compact -offset
.It Ar first
新規 (非再試行) 呼び出しセットアップの度に、最初の番号から開始します。
新規 (非再試行) 呼設定 (call setup) の度に、最初の番号から開始します。
.It Ar last
新規 (非再試行) 呼び出しセットアップの度に、
成功裏に接続を確立できた最後の番号から開始します。
新規 (非再試行) 呼設定の度に、
接続確立が成功した最後の番号から開始します。
.It Ar next
新規 (非再試行) 呼び出しセットアップの度に、
新規 (非再試行) 呼設定の度に、
最後に使用したものの次の番号から開始します。
.El
@ -471,14 +472,14 @@ ratetype=0
.Em "着番号情報要素 (Called Party Number Information Element)"
に埋め込まれます。
.Pp
本キーワードは、ipr インタフェース用のために必須です。
本キーワードは、ipr インタフェースのために必須です。
.\" 原文の .em (Execute Macro) は、引数無しの場合効果が無いので削除
.\" horikawa@jp.freebsd.org 1999/01/19
どれかひとつが成功するまでいくつかの番号に対して試行させるために、
複数回指定可能です。
複数回指定して、
どれかひとつが成功するまでいくつかの番号に対して試行させることもできます。
.It Li remote-phone-incoming
内向き呼び出しを確認するために使用する、リモートの電話番号です。
着呼を確認するために使用する、リモートの電話番号です。
リモートサイトがダイヤルインするとき、
ローカルシステムに対して接続する権限がある
正しいリモートサイトであることを確認するために、
@ -489,12 +490,12 @@ ratetype=0
.Pp
本キーワードは ipr インタフェースのために必須です。
.Pp
本キーワードを、ワイルドカードパラメータ '*' として、
本キーワードにワイルドカードパラメータ '*' を渡して、
誰もがダイヤルイン可能とできます。
.It Li unitlength
秒数による課金単位の長さ。
アイドルタイムとともに使用して、接続をいつハングアップするのかを決定します。
アイドル時間とともに使用して、いつ接続を切るのかを決定します。
(省略可能)
.It Li unitlengthsrc
@ -515,11 +516,11 @@ unitlength
.It Ar rate
設定ファイルにおいてキーワード
.Em ratetype
で指定される料金ファイル中で指定される unitlength を使用します。
で指定される料金ファイル中の unitlength を使用します。
.It Ar aocd
ISDN 回線において AOCD を申し込んでいる場合、
動的に計算される unitlength を使用します。
(AOCD は ```Advice Of Charge During the call (呼び出し中の課金アドバイス)''
(AOCD は ```Advice Of Charge During the call (呼の間の課金アドバイス)''
の頭文字で、遠距離通信 (すなわち電話) 業者が提供する、
課金単位を示すサービスです)。
.El
@ -556,9 +557,9 @@ usrdevicename
.Em downtries
と
.Em downtime
を使用可能とするために使用します。
を有効にするために使用します。
(回線ビジーの場合等) 遷移に失敗する場合に、
過度のダイヤルアクティビティを避けるために、
過度のダイヤル動作を避けるために、
.Nm isdnd
が IP インタフェースの有効・無効を動的に切り替えるために使用します。
本パラメータは省略可能であり、デフォルトで
@ -589,43 +590,43 @@ usrdevicename
.Sh アイドル時間の計算とショートホールドモード
.Bl -tag -width incoming calls -compact
.It Li 内向き呼び出し
呼び出し側が課金構造のほとんどを知っているものと見倣すので、キーワード
.It Li 着呼
呼び出し側が課金構造などのほとんどを知っているものと見なすので、キーワード
.Em idletime-incoming
のみが内向き呼び出しに機能します。
のみが着呼に機能します。
.Pp
内向き呼び出しに対しては回線は定常的に監視され、
着呼に対しては回線は定常的に監視され、
.Em idletime-incoming
で指定する秒数の期間トラフィックが無い場合には、呼び出しは閉じられます。
で指定する秒数の期間トラフィックが無い場合には、呼は閉じられます。
.Pp
典型的には、
.Em idletime-incoming
は最終手段として使用するため、課金単位時間よりもずっと大きな値を設定します。
典型的な値は 1 ～ 5 分です。
.It Li 外向き呼び出し
外向き呼び出しの切断時間を、2 種類の方法のいずれかに設定可能です:
.It Li 発呼
発呼の切断時間を、2 種類の方法のいずれかに設定可能です:
.Bl -tag -width shorthold mode -compact
.It Li 単純モード
単純なモードであり、
.Em unitlength
は 0 (ゼロ) であり
の選択値は 0 (ゼロ) であり
.Em idletime-outgoing
は 0 より大きいことが必要です。
.Pp
外向きのトラフィクは定常的に監視され、
送信のトラフィックは定常的に監視され、
.Em idletime-outgoing
で指定された秒数だけトラフィックが無かった場合、呼び出しは閉じられます。
で指定された秒数だけトラフィックが無かった場合、呼は閉じられます。
.Pp
単純なモードの典型値は 10 ～ 30 秒です。
.It Li ショートホールドモード
ショートホールドモードでは、選択された
ショートホールドモードでは、
.Em unitlength
と
.Em idletime-outgoing
は 0 (ゼロ) より大きいことが必要であり、
の選択値は 0 (ゼロ) より大きいことが必要であり、
.Em earlyhangup は 0 (ゼロ) 以上であることが必要です
。
@ -647,7 +648,7 @@ usrdevicename
回線にトラフィックが無いかチェックされます。
チェックウィンドウ (check-window) の期間にトラフィックが検出された場合、
次の単位 (unit) の先頭から同じ手続きが再度開始されます。
チェックウィンドウ (check-window) の期間トラフィックが検出されない場合、
チェックウィンドウの期間トラフィックが検出されない場合、
チェックウィンドウ終了時に回線が閉じられます、
.Pp
注釈:

919
ja/man/man7/security.7
View file

@ -3,432 +3,615 @@
.\" the source tree.
.\"
.\" %Id: security.7,v 1.4 1998/12/26 05:19:42 dillon Exp %
.\" jpman %Id: security.7,v 1.2 1999/01/31 11:05:10 horikawa Chk %
.\" jpman %Id: security.7,v 1.3 1999/02/11 11:18:48 vanitas Stab %
.\"
.Dd December 20, 1998
.Dt SECURITY 7
.Os
.Sh NAME
.Sh 名称
.Nm security
.Nd introduction to security under FreeBSD
.Sh DESCRIPTION
.Nd FreeBSD におけるセキュリティ入門
.Sh 解説
.Pp
Security is a function that begins and ends with the system administrator.
While all
セキュリティは、システム管理者とともに始まり、システム管理者と
ともに終る機能です。すべての
.Bx
systems are inherently multi-user capable, the job of building and
maintaining security mechanisms to keep those users 'honest' is probably
one of the single largest undertakings of the sysadmin. Machines are
only as secure as you make them, and security concerns are ever competing
with the human necessity for convenience. UNIX systems,
in general, are capable of running a huge number of simultaneous processes
and many of these processes operate as servers - meaning that external entities
can connect and talk to them. As yesterday's mini-computers and mainframes
become today's desktops, and as computers become networked and internetworked,
security becomes an ever bigger issue.
システムは昔からマルチユーザに対応しています。セキュリティの仕組みを
組み込んで維持することで、ユーザを
.Sq 正直に
し続ける仕事は、システム管理者の最も大きな責務の一つでしょう。マシンは、
管理者が設定しただけのセキュリティしか示しません。セキュリティに関する
問題は、むしろ、便利さを求める人間との競合問題です。一般に、
.Ux
システムは莫大な数のプロセスを同時に実行させることも、また、その多くを
サーバとして動作させることもできます。これは、外部の何者かが
接続してきて、サーバプロセスと会話することができるということを
意味します。昨日までのミニコンピュータとメインフレームは、今日では
デスクトップコンピュータとなり、かつ、それらはネットワークで結ばれて
インターネットと接続されるようになりました。これにより、セキュリティは
昔と比べてはるかに大きな問題となっています。
.Pp
Security concerns can be split up into several categories:
セキュリティに関する問題は、いくつかのカテゴリに分類することができます。
.Bl -enum -offset indent
.It
Denial of service attacks
サービス不能攻撃
.It
User account compromises
ユーザアカウントにかかる危険
.It
Root compromise through accessible servers
アクセス可能なサーバを経由した root 権限にかかる危険
.It
Root compromise via user accounts
ユーザアカウントを通した root 権限にかかる危険
.El
.Pp
A denial of service attack is an action that deprives the machine of needed
resources. Typically, D.O.S. attacks are brute-force mechanisms that attempt
to crash or otherwise make a machine unusable by overwhelming its servers or
network stack. Some D.O.S. attacks try to take advantages of bugs in the
networking stack to crash a machine with a single packet. The latter can
only be fixed by applying a bug fix to the kernel. Attacks on servers can
often be fixed by properly specifying options to servers to limit the load
they incur on the system under adverse conditions. Brute-force network
attacks are harder to deal with. A spoofed-packet attack, for example, is
nearly impossible to stop short of cutting your system off from the internet.
サービス不能攻撃とは、マシンから必要な資源を奪う行為です。
サービス不能攻撃は、普通は、そのマシンで実行されるサーバや
ネットワークスタックを圧倒して、マシンを使えなくしたりクラッシュさせようと
するような力任せの仕組みです。サービス不能攻撃のいくつかは、
ネットワークスタックのバグを利用して、パケット一つでマシンを
クラッシュさせようとします。後者は、
カーネルにバグ修正を施すことによってのみ修正することができます。
サーバプロセスに対する攻撃は、サーバのオプションを適切に指定して、
逆境状況のシステムにおいて、サーバプロセスが引き起こす負荷に限界を設けることで
修正することができます。これらに比べると、ネットワークへの力任せの攻撃への
対応はずっと難しくなります。たとえば、偽造パケットによる攻撃
.Pq spoof-packet attack
は、インターネットからシステムを切り離す以外の方法では、抑止することは
ほとんど不可能です。
.Pp
A user account compromise is even more common then a D.O.S. attack. Many
sysadmins still run standard telnetd, rlogind, rshd, and ftpd servers on their
machines. These servers, by default, do not operate over encrypted
connections. The result is that if you have any moderate-sized user base,
one or more of your users logging into your system from a remote location
(which is the most common and convenient way to login to a system) will
have his or her password sniffed. The attentive system admin will analyze
his remote access logs occasionally looking for suspicious source addresses
even for successful logins.
ユーザアカウントを危険に晒すことは、サービス不能攻撃よりは多少はありふれた
ものです。このご時勢でも、システム管理者の多くは、自分たちのマシンで
標準の telnetd, rlogind, rshd, ftpd サーバを実行させています。これらの
サーバは、デフォルトでは、暗号化されたコネクション上で動作していません。
その結果、抱えているユーザ数が標準的な大きさならば、リモート
.Pq そのシステムにログインするのに最も普通で便利な場所
からログインしているユーザのうち一人以上は、パスワードを覗き見られて
しまうでしょう。
システム管理者が注意深いならば、たとえログインが成功していたとしても、
リモートアクセスログをときどき解析して、疑わしいソースアドレスを探すものです。
.Pp
One must always assume that once an attacker has access to a user account,
the attacker can break root. However, the reality is that in a well secured
and maintained system, access to a user account does not necessarily give the
attacker access to root. The distinction is important because without access
to root the attacker cannot generally hide his tracks and may, at best, be
able to remove that user's files and crash the machine, but not touch anyone
else's files.
ひとたび攻撃者がユーザアカウントへのアクセス権を入手すると、攻撃者が
root の権限を破る可能性があることを仮定するべきです。しかし、
セキュリティを十分保ち、手入れの行き届いたシステムにおいては、
あるユーザアカウントへのアクセスが可能となっても、攻撃者に必ずしも
root へのアクセス権を与えるとは限らないのが現実です。この違いは重要です。
というのは、root へのアクセス権がなければ、一般的に、攻撃者は自分の
侵入の痕跡を隠蔽することができませんし、そのユーザのファイルを消して
マシンをクラッシュさせることができるのがせいぜいで、他のユーザの
ファイルには手出しできません。
.Pp
System administrators must keep in mind that there are several ways to break
root on a machine. The attacker may know the root password, the attacker
may find a bug in a root-run server and be able to break root over a network
connection to that server, or the attacker may know of a bug in an suid-root
program that allows the attacker to break root once he has broken into a
user's account.
システム管理者は、あるマシン上で root の権限を破る方法がいくつかあることを
心しておかねばなりません。攻撃者が root のパスワードを知ってしまうかも
しれません。攻撃者が root の権限で実行されるサーバのバグを見つけ、
ネットワークからそのサーバへ接続して root の権限を破ることができるかも
しれません。ひとたびユーザアカウントを破ると、ユーザアカウントから
root の権限を破ることが可能であるバグを持つ suid-root プログラムの
存在を、攻撃者は知っているかもしれません。
.Pp
Security remedies are always implemented in a multi-layered 'onion peel'
approach and can be categorized as follows:
セキュリティを改善する方法は、常に、
.Sq タマネギの皮剥き
のように
複数の層のアプローチで実装されます。これらは次のように分類できます。
.Bl -enum -offset indent
.It
Securing root and staff accounts
root とスタッフのアカウントの安全性を高める。
.It
Securing root - root-run servers and suid/sgid binaries
root の安全性を高める - root 権限のサーバと suid/sgid バイナリ。
.It
Securing user accounts
ユーザアカウントの安全性を高める。
.It
Securing the password file
パスワードファイルの安全性を高める。
.It
Securing the kernel core, raw devices, and filesystems
カーネルのコア、raw デバイス、ファイルシステムの安全性を高める。
.It
Checking file integrity: binaries, configuration files, and so forth
ファイルの完全性のチェック: バイナリ、設定ファイルなど。
.It
Paranoia
偏執狂的方法。
.El
.Sh SECURING THE ROOT ACCOUNT AND SECURING STAFF ACCOUNTS
.Sh root アカウントとスタッフアカウントの安全性を高める
.Pp
Don't bother securing staff accounts if you haven't secured the root
account. Most systems have a password assigned to the root account. The
first thing you do is assume that the password is 'always' compromised.
To secure the root account you make sure that it is not possible to login
to the root account using the root password from a random user account or
over the network. If you haven't already, configure telnetd, rlogind, and
all other servers that handle login operations to refuse root logins, period,
whether the right password is given or not. Allow direct root logins only
via the system console. The '/etc/ttys' file comes in handy here and is
secure by default on most systems, but a good sysadmin always checks to make
sure.
root のアカウントの安全性を確保しないうちからスタッフのアカウントの安全性を
うんぬんしてもしかたがありません。ほとんどのシステムでは、root アカウントに
割り当てたパスワードがひとつあります。まず最初にすべきことは、
このパスワードは
.Sq いつでも
危険に晒されていると仮定することです。root アカウントの安全性を確保する
ためには、ネットワーク越しに、あるいはどれか一般ユーザのアカウントから、
root のパスワードを使って root アカウントにログインすることが決して
できないことを確実にすることです。正しいパスワードが与えられようが
与えられまいが、telnetd, rlogind, その他ログイン処理を行なうサーバ
すべてで root でのログインを拒絶するように設定していないとするなら、
今すぐそういうふうに設定して下さい。直接 root でログインできるのは、
システムコンソールからだけにして下さい。ここで役に立つのが
.Sq /etc/ttys
ファイルです。ほとんどのシステムでは、デフォルトで安全ですが、
優れたシステム管理者は、設定がそうなっているか常にチェックを怠らない
ものです。
.Pp
Of course, as a sysadmin you have to be able to get to root, so we open up
a few holes. But we make sure these holes require additional password
verification to operate. One way to make root accessible is to add appropriate
staff accounts to the wheel group (in /etc/group). The staff members placed
in the wheel group are allowed to 'su' to root. You should never give staff
members native wheel access via their entry in the password file... put staff
in a 'staff' group or something and only add those that really need root to
the wheel group. Unfortunately the wheel mechanism still allows an intruder to
break root if the intruder has gotten hold of your password file - he need only
break the root password and the password of one of the staff accounts that
happens to be in the wheel group. So while the wheel mechanism is usable,
it isn't much safer then not having a wheel group at all.
システム管理者として、自分は root になれるようにしておかねばならないの
はもちろんですから、穴をいくつか空けておきます。しかし、それらの穴を
動作させるには、さらに追加のパスワード認証が必要であるようにして
おきます。root でアクセス可能とする方法の一つとして、
適切なスタッフアカウントを
.Pq /etc/group の
wheel グループに加えることがあります。
wheel グループに置かれたスタッフメンバには、
.Sq su
を使って root になることが許されます。スタッフメンバに、
パスワードファイルのエントリでそのまま wheel のアクセス権を
与えてはいけません。スタッフは、
.Sq staff
かその類のグループに置き、その中で本当に root になる必要がある人
だけを wheel グループに加えるようにします。残念ながら、wheel の
仕組みだけだと、侵入者がパスワードファイルを手に入れると、攻撃者が
破る必要があるのは root のパスワードか、wheel グループにたまたま属す
staff アカウントの一つのパスワードだけです。wheel の仕組みは有益
ですが、wheel グループがまったく存在しない状況と比べてそれほど
安全なわけではありません。
.Pp
An indirect way to secure the root account is to secure your staff accounts
by using an alternative login access method and *'ing out the crypted password
for the staff accounts. This way an intruder may be able to steal the password
file but will not be able to break into any staff accounts (or, indirectly,
root, even if root has a crypted password associated with it). Staff members
get into their staff accounts through a secure login mechanism such as
kerberos(1) or ssh(1) (see /usr/ports/security/ssh) using a private/public
key pair. When you use something like kerberos you generally must secure
the machines which run the kerberos servers and your desktop workstation.
When you use a public/private key pair with ssh, you must generally secure
the machine you are logging in FROM (typically your workstation), but you can
also add an additional layer of protection to the key pair by password
protecting the key pair when you create it with ssh-keygen(1). Being able
to *-out the passwords for staff accounts also guarantees that staff members
can only login through secure access methods that you have setup. You can
thus force all staff members to use secure, encrypted connections for
all their sessions which closes an important hole used by many intruders: That
of sniffing the network from an unrelated, less secure machine.
root アカウントの安全性を高める間接的な方法として、別のログインアクセス
の方法を用いて、スタッフのアカウントの暗号化パスワードを\ * にして
おくことで、スタッフのアカウントの安全性を高めるものがあります。この方法
だと、侵入者がパスワードファイルを盗むことができるかもしれませんが、
スタッフアカウントを破ることはできないでしょう。また、たとえ root が暗号化
パスワードをパスワードファイルに付けていたとしても、間接的には root
アカウントも破ることができないでしょう。
スタッフメンバがスタッフアカウントでログインする際には、
.Xr kerberos 1
や
.Xr ssh 1
.Po
.Pa /usr/ports/security/ssh
参照
.Pc
のような、公開鍵 / 秘密鍵の鍵の組を使う
安全性の高いログインの仕組みを使います。kerberos のような仕掛けを使う場合、
一般に、kerberos サーバを実行するマシンと自分のデスクトップ
ワークステーションとの安全性を確保しなければなりません。ssh で
公開鍵 / 秘密鍵の鍵の組を使う場合、一般に、ログイン元マシン
.Pq 通常は自分のワークステーション
の安全性を確保しなければなりません。ここで、
.Xr ssh-keygen 1
で鍵の組を生成する際、鍵の組をパスワードで防御することにより、
鍵の組を防護するための層を追加することもできます。スタッフアカウントの
パスワードを\ * で外すことができることにより、スタッフメンバが
管理者自身が設定した安全性の高い方法でのみログインできることも保証
できます。かくして、多くの侵入者が使う重大なセキュリティの穴
.Pq 安全性の低い無関係なマシンからネットワークを覗き見る方法
のないセッションを提供する、安全性の高い暗号化されたコネクションを
使うことを、すべてのスタッフメンバに強制することができるのです。
.Pp
The more indirect security mechanisms also assume that you are logging in
from a more restrictive server to a less restrictive server. For example,
if your main box is running all sorts of servers, your workstation shouldn't
be running any. In order for your workstation to be reasonably secure
you should run as few servers as possible, up to and including no servers
at all, and you should run a password-protected screen blanker.
Of course, given physical access to
a workstation an attacker can break any sort of security you put on it.
This is definitely a problem that you should consider but you should also
consider the fact that the vast majority of break-ins occur remotely, over
a network, from people who do not have physical access to your workstation or
servers.
より間接的なセキュリティの仕組みは、より制限の強いサーバから制限の弱い
サーバへログインすることを前提としています。例えば、主マシンで、
すべての種類のサーバを実行させている場合、ワークステーションではそれらの
サーバを実行させてはなりません。ワークステーションの安全性を比較的
高めておくためには、実行するサーバの数を、果てはサーバなしまで、
できるだけ減らしておくべきです。また、パスワード防護された
スクリーンセーバを走らせておくべきです。
ワークステーションへの物理的アクセスが与えられたとすると、攻撃者は
管理者が設定したいかなる種類のセキュリティをもうち破ることができるのは
もちろんのことです。これは、管理者として考えておかねばならない決定的な
問題ですが、システム破りの大多数は、ネットワーク経由でリモートから、
ワークステーションやサーバへの物理的アクセス手段を持たない人々によって
行なわれるという事実も、また、念頭に置いておく必要があります。
.Pp
Using something like kerberos also gives you the ability to disable or
change the password for a staff account in one place and have it immediately
effect all the machine the staff member may have an account on. If a staff
member's account gets compromised, the ability to instantly change his
password on all machines should not be underrated. With discrete passwords,
changing a password on N machines can be a mess. You can also impose
re-passwording restrictions with kerberos: not only can a kerberos ticket
be made to timeout after a while, but the kerberos system can require that
the user choose a new password after a certain period of time (say, once a
month).
.Sh SECURING ROOT - ROOT-RUN SERVERS AND SUID/SGID BINARIES
kerberos のような方法を使うことで、スタッフアカウントのパスワードの変更
もしくは停止を一箇所で行なうことと、スタッフメンバがアカウントを持つ
すべてのマシンに即時にその効果を及ぼすことが可能となります。スタッフメンバの
アカウントが危険に晒されたときに、すべてのマシンでその人のパスワードを
即座に変更する機能を甘く見てはいけません。パスワードが分散されていると、
N 台のマシンでパスワードを変更することは、てんやわんやの事態を招く可能性が
あります。kerberos による再パスワード制限
.Pq re-passwording restriction
を課することもできます。これを使うことにより可能となることは、
ある kerberos チケットをしばらくしてからタイムアウトにすることだけでなく、
kerberos システムがユーザに一定期間
.Pq 例えば、1 ヶ月に 1 回
の後に新しいパスワードを選ぶことを要求することもできます。
.Sh root の安全性を高める - root 権限のサーバと suid/sgid バイナリ
.Pp
The prudent sysadmin only runs the servers he needs to, no more, no less. Be
aware that third party servers are often the most bug-prone. For example,
running an old version of imapd or popper is like giving a universal root
ticket out to the entire world. Never run a server that you have not checked
out carefully. Many servers do not need to be run as root. For example,
the ntalk, comsat, and finger daemons can be run in special user 'sandboxes'.
A sandbox isn't perfect unless you go to a large amount of trouble, but the
onion approach to security still stands: If someone is able to break in
through a server running in a sandbox, they still have to break out of the
sandbox. The more layers the attacker must break through, the lower the
likelihood of his success. Root holes have historically been found in
virtually every server ever run as root, including basic system servers.
If you are running a machine through which people only login via sshd and
never login via telnetd or rshd or rlogind, then turn off those services!
用心深いシステム管理者は、自分に必要なサーバプロセスだけを過不足なく
実行させるものです。第三者製のサーバはしばしばバグの温床であることに
注意して下さい。例えば、古いバージョンの imapd や popper を実行させ
ておくということは、全世界に共通の root の切符を与えているようなものです。
自分で注意深くチェックしていないサーバは、決して実行してはいけません。
サーバの多くは root で実行させる必要はありません。例えば、ntalk, comsat,
finger デーモンを、特別の「砂場
.Pq sandbox
」ユーザで実行させることができます。
.\"kuma hellofalot of trouble って何や？
.\" hell of a lot of trouble みたいですね。;-) (金ん田 '99.02.11)
管理者が膨大な数の問題に直面しない限り、砂場は完璧では
ありませんが、セキュリティに関するタマネギ的アプローチはここでも
成り立ちます。砂場で実行されているサーバプロセスを経由して侵入を
果たすことができたとしても、攻撃者はさらに砂場から外に脱出しなければ
なりません。攻撃者が通過せねばならない層の数が増えれば増えるほど、
それだけ攻撃者が侵入に成功する確率が減ります。root の抜け穴は
歴史的に、基本システムサーバも含め、
root 権限で実行されるほとんどすべてのサーバプロセスに発見されています。
ユーザが sshd 経由でのみログインし、
telnetd, rshd, rlogind 経由でログインすること
が決してないマシンをお使いなら、それらのサービスを停止させて下さい。
.Pp
FreeBSD now defaults to running ntalkd, comsat, and finger in a sandbox.
Another program which may be a candidate for running in a sandbox is
named(8). The default rc.conf includes the arguments necessary to run
named in a sandbox in a commented-out form. Depending on whether you
are installing a new system or upgrading an existing system, the special
user accounts used by these sandboxes may not be installed. The prudent
sysadmin would research and implement sandboxes for servers whenever possible.
.Bx Free
では、今では ntalkd, comsat, finger は砂場で実行させることが
デフォルトになっています。次に砂場で実行させるべきプログラムの候補として、
.Xr named 8
があります。デフォルトの rc.conf ファイルには、named を砂場で実行する
ために必要な引数がコメントアウトされた形式で含められています。新しい
システムをインストールしているか、それとも既存のシステムを
アップグレードして使っているかに依存しますが、砂場として使用する
特別のユーザアカウントがインストールされていないかもしれません。用心深い
システム管理者は研究を怠らず、可能なところではつねにサーバに砂場を仕込む
ものです。
.Pp
There are a number of other servers that typically do not run in sandboxes:
sendmail, popper, imapd, ftpd, and others. There are alternatives to
some of these, but installing them may require more work then you are willing
to put (the convenience factor strikes again). You may have to run these
servers as root and rely on other mechanisms to detect break-ins that might
occur through them.
通常、砂場で実行しないサーバが他にいくつかあります。sendmail, popper,
imapd, ftpd などです。これらのうちいくつかには代わりがありますが、
代わりのものをインストールするには、それだけ多くの仕事が必要になるので、
結局これらを喜んで入れてしまいます
.Pq 簡単度がまたも勝利を収めるわけです
。
これらのサーバは、root 権限で実行せねばならず、これら経由で生じる侵入の
検出のためには、他の仕組みに依存せねばならないかもしれません。
.Pp
The other big potential root hole in a system are the suid-root and sgid
binaries installed on the system. Most of these binaries, such as rlogin,
reside in /bin, /sbin, /usr/bin, or /usr/sbin. While nothing is 100% safe,
the system-default suid and sgid binaries can be considered reasonably safe.
Still, root holes are occasionally found in these binaries. A root hole
was found in Xlib in 1998 that made xterm (which is typically suid) vulnerable.
It is better to be safe then sorry and the prudent sysadmin will restrict suid
binaries that only staff should run to a special group that only staff can
access, and get rid of (chmod 000) any suid binaries that nobody uses. A
server with no display generally does not need an xterm binary. Sgid binaries
can be almost as dangerous. If an intruder can break an sgid-kmem binary the
intruder might be able to read /dev/kmem and thus read the crypted password
file, potentially compromising any passworded account. An intruder that breaks
the tty group can write to almost user's tty. If a user is running a terminal
program or emulator with a talk-back feature, the intruder can potentially
generate a data stream that causes the user's terminal to echo a command, which
is then run as that user.
.Sh SECURING USER ACCOUNTS
システムの root 権限の潜在的な穴で他に大きなものとして、システムに
インストールされた suid-root/sgid バイナリがあります。rlogin など、
これらのバイナリのほとんどは、/bin, /sbin, /usr/bin, /usr/sbin に
存在します。100% 安全なものは存在しないとはいえ、システムデフォルトの
siud/sgid バイナリは比較的安全といえます。それでもなお、root の穴が
これらのバイナリにときおり発見されています。1998 年に Xlib で見つかった
root の穴は、xterm
.Pq 普通、suid 設定されています
を攻撃可能にしていました。
安全である方がよいので、用心深いシステム管理者は残念に思いながらも、
スタッフのみが実行する必要がある suid バイナリは、スタッフのみが
アクセス可能な特別なグループに含めるように制限を加え、
誰も使わない suid バイナリは chmod 000 して片付けてしまうでしょう。
ディスプレイを持たないサーバは、一般的に xterm のバイナリを必要としません。
sgid バイナリもほとんど同様の危険な存在になり得ます。
侵入者が sgid-kmem のバイナリを破ることができた場合、
その侵入者は /dev/kmem を読み出すことができるようになります。
つまり、暗号化されたパスワードファイルを読み出すことができる
ようになるので、パスワードを持つどのアカウントをも、
.Pq 潜在的な
危険に晒すことになります。
tty グループを破った侵入者は、ほとんどすべてのユーザの端末に書き込みが
できます。talk-back 機能を持つ端末プログラムやエミュレータをユーザが実行
していると、
.Pq 結局、そのユーザとして実行される
コマンドをユーザの端末にエコーさせるデータストリームを
侵入者が生成できる可能性があります。
.Sh ユーザアカウントの安全性を高める
.Pp
User accounts are usually the most difficult to secure. While you can impose
Draconian access restrictions on your staff and *-out their passwords, you
may not be able to do so with any general user accounts you might have. If
you do have sufficient control then you may win out and be able to secure the
user accounts properly. If not, you simply have to be more vigilant in your
monitoring of those accounts. Use of ssh and kerberos for user accounts is
more problematic, but still a very good solution compared to a crypted
password.
.Sh SECURING THE PASSWORD FILE
ユーザアカウントは、普通、安全性を高めることが最も困難です。
スタッフに対して、アテナイのドラコのような厳格なアクセス制限を課し、
スタッフのパスワードを\ * で外すことができるとはいえ、管理者が持ちうる
一般ユーザすべてのアカウントに対して同じことはできないかも知れません。
十分な管理を保つならば、管理者は勝利し、ユーザの
アカウントを適切な状態で安全を確保できるかもしれません。それが
保てないならば、一般ユーザのアカウントをモニタしていっそう気を配るように
するしかありません。一般ユーザアカウントでの ssh や kerberos の利用は、
いろいろ問題をはらんでいます。それでも、暗号化パスワードと比較すると、
はるかに良い解です。
.Sh パスワードファイルの安全性を高める
.Pp
The only sure fire way is to *-out as many passwords as you can and
use ssh or kerberos for access to those accounts. Even though the
crypted password file (/etc/spwd.db) can only be read by root, it may
be possible for a intruder to obtain read access to that file even if the
attacker cannot obtain root-write access.
できるだけ多くのパスワードを\ * で外し、それらのアカウントのアクセスには
ssh や kerberos を使うようにすることが、唯一の確実な方法です。たとえ暗号化
パスワードファイル
.Pq /etc/spwd.db
が root でのみ読み出し可能だとしても、
たとえ root の書き込み権限が得られないにしても、侵入者がそのファイルの
読み出しアクセス権限を得ることは可能かも知れません。
.Pp
Your security scripts should always check for and report changes to
the password file (see 'Checking file integrity' below).
.Sh SECURING THE KERNEL CORE, RAW DEVICES, AND FILESYSTEMS
セキュリティスクリプトは常にパスワードファイルの変更をチェックし、報告
するようにすべきです (後述の「ファイルの完全性のチェック」を参照して下さい)。
.Sh カーネルのコア、raw デバイス、ファイルシステムの安全性を高める
.Pp
If an attacker breaks root he can do just about anything, but there
are certain conveniences. For example, most modern kernels have a
packet sniffing device driver built in. Under FreeBSD it is called
the 'bpf' device. A intruder will commonly attempt to run a packet sniffer
on a compromised machine. You do not need to give the intruder the
capability and most systems should not have the bpf device compiled in.
Unfortunately, there is another kernel feature called the Loadable Kernel
Module interface. An enterprising intruder can use an LKM to install
his own bpf device or other sniffing device on a running kernel. If you
do not need to use the module loader, turn it off in the kernel configuration
with the NO_LKM option.
root の権限を破ると、攻撃者はほとんど何でもできますが、
もっと簡便なこともいくつかあります。例えば、最近のカーネルのほとんどでは、
組み込みのパケット覗き見デバイス
.Pq packet sniffing device
ドライバを備えています。
.Bx Free
では
.Sq bpf
デバイスと呼ばれています。侵入者は普通、危険に晒された
マシンでパケット覗き見プログラムを実行させようと試みます。侵入者に
わざわざそういう機能を提供する必要はないので、ほとんどのシステムで bpf
デバイスを組み込むべきではありません。不幸なことに、ローダブルカーネル
モジュール
.Pq Loadable Kernel Module:LKM
インタフェースと呼ばれる
カーネル機能があります。やる気まんまんの侵入者は、LKM を使って
自分独自の bpf もしくはその他覗き見デバイスを動作中のカーネルに
インストールすることが可能です。
モジュールローダを使う必要がないのであれば、カーネル設定で
NO_LKM オプションを設定してこの機能を無効にして下さい。
.Pp
But even if you turn off the bpf device, and turn off the module loader,
you still have /dev/mem and /dev/kmem to worry about. For that matter,
the intruder can still write raw devices. To avoid this you have to run
the kernel at a higher secure level... at least securelevel 1. The securelevel
can be set with a sysctl on the kern.securelevel variable. Once you have
set the securelevel to 1, write access to raw devices will be denied and
special chflags flags, such as 'schg', will be enforced. You must also ensure
that the 'schg' flag is set on critical startup binaries, directories, and
script files - everything that gets run up to the point where the securelevel
is set. This might be overdoing it, and upgrading the system is much more
difficult when you operate at a higher secure level. You may compromise and
run the system at a higher secure level but not set the schg flag for every
system file and directory under the sun.
.Sh CHECKING FILE INTEGRITY: BINARIES, CONFIG FILES, ETC
bpf デバイスを外し、モジュールローダを無効にしても、/dev/mem と /dev/kmem
という悩みの種がまだ残っています。この問題に関しては、侵入者は raw
デバイスに書き込むこともできます。この問題を避けるため、システム管理者は
カーネルをより高い安全レベル
.Pq securelevel
、少なくとも安全レベル 1 で実行させる必要があります。
sysctl を使って kern.securelevel 変数に安全レベルを設定することが
できます。ひとたび安全レベルに 1 を設定すると、
raw デバイスに対する書き込みアクセスは拒否され、例えば
.Sq schg
のような
特別な chflags フラグが効果を発揮します。これに加えて、
起動において重要なバイナリ・ディレクトリ・スクリプトファイルなど、
安全レベルが設定されるまでの間に実行されるものすべてに対しても
.Sq schg
フラグを確実に on にしておく必要があります。この設定をやり過ぎても
構いませんが、より高い安全レベルで動作している場合、システムの
アップグレードがはるかに困難になります。システムをより高い安全レベルで
実行させるようにするが、お天道さまの下にあるすべてのシステムファイルと
ディレクトリに schg フラグを設定しないという妥協をする方法もあります。
.Sh ファイルの完全性のチェック: バイナリ、設定ファイルなど
.Pp
When it comes right down to it, you can only protect your core system
configuration and control files so much before the convenience factor
rears its ugly head. The last layer of your security onion is perhaps
the most important - detection.
ことここに至るとシステム管理者にできることは、
便利度がその醜い頭を上げない程度に、
コアシステムの設定 / 制御ファイルを防御することだけです。
セキュリティのタマネギの最後の層はおそらく最も重要なもの、すなわち探知です。
.Pp
The only correct way to check a system's file integrity is via another,
more secure system. It is fairly easy to setup a 'secure' system: you
simply do not run any services on it. With a secure system in place you
can then give it access to other system's root spaces via ssh. This may
seem like a security breech, but you have to put your trust somewhere and
as long as you don't do something stupid like run random servers it really
is possible to build a secure machine. When I say 'secure' here, I assuming
physical access security as well, of course. Given a secure machine with
root access on all your other machines, you can then write security scripts
ON the secure machine to check the other machines on the system. The most
common way of checking is to have the security script scp(1) over a find
and md5 binary and then ssh a shell command to the remote machine to md5
all the files in the system (or, at least, the /, /var, and /usr partitions!).
The security machine copies the results to a file and diff's them against
results from a previous run (or compares the results against its own
binaries), then emails each staff member a daily report of differences.
システムファイルの完全性をチェックする唯一の正しい方法は、別の、より安全な
システム経由で行なう方法だけです。
.Sq 安全
なシステムを準備することは比較的
容易です。単に、サービスを一切実行しないようにするだけです。安全なシステム
を用いて、ssh 経由で他のシステムの root 空間にアクセスします。これは
セキュリティの末端のように見えるかもしれません。しかし、管理者には信頼を
どこかに置く必要があります。いきあたりばったりでサーバプロセスを
実行するような馬鹿げたことをしない限りは、安全度の高いマシンを構築する
ことは本当に可能です。ここで
.Sq 安全
という場合、物理アクセスに対する
セキュリティをも含めて仮定していることはもちろんです。安全なマシンで、
他のすべてのマシンに root のアクセス権限を持つものが得られると、
「安全なマシンの上で」システムの他のマシンをチェックする
セキュリティスクリプトを書くことができるようになります。
最も普通のチェック方法は、セキュリティスクリプトで、
まず、find と md5 のバイナリファイルをリモートマシンに
.Xr scp 1
してから、
リモートシステムのすべてのファイル
.Pq もしくは、少なくとも /, /var, /usr パーティション!
に対して md5 を適用するシェルコマンドを
ssh を使ってリモートマシンで実行するものです。
安全なマシンは、チェック結果をファイルにコピーし、前回のチェック結果と
diff を取り
.Pq または、安全なマシン自身のバイナリと比較する
違いを
毎日のレポートとしてスタッフメンバひとりひとりにメールを送ります。
.Pp
Another way to do this sort of check is to NFS export the major filesystems
from every other machine to the security machine. This is somewhat more
network intensive but also virtually impossible for an intruder to detect
or spoof.
この種のチェックを行なうもう一つの方法として、安全なマシンに対して、
他のマシンの主なファイルシステムを NFS export する方法があります。
このやり方はいくらかネットワークに負荷を掛けることになりますが、
侵入者がチェックを探知したり偽造したりすることは、
事実上不可能になります。
.Pp
A good security script will also check for changes to user and staff members
access configuration files: .rhosts, .shosts, .ssh/authorized_keys, and
so forth... files that might fall outside the prevue of the MD5 check.
優れたセキュリティスクリプトは、一般ユーザやスタッフメンバのアクセス制御
ファイル: .rhosts, .shosts, .ssh/authorized_keys など、MD5 での精細な
チェックから洩れそうなファイルの変更をチェックします。
.Pp
A good security script will check for suid and sgid binaries on all
filesystems and report their absolute existence as well as a diff against
the previous report or some baseline (say, make a baseline once a week).
While you can turn off the ability to run suid and sgid binaries on certain
filesystems through the 'nosuid' option in fstab/mount, you cannot turn this
off on root and anyone who breaks root can just install their binary their.
If you have a huge amount of user disk space, though, it may be useful to
disallow suid binaries and devices ('nodev' option) on the user partitions
so you do not have to scan them for such. I would scan them anyway, though,
at least once a week, since the object of this onion layer is detection of
a break-in.
優れたセキュリティスクリプトは、すべてのファイルシステム上で suid/sgid
バイナリに対してチェックを行ない、前回のチェック結果もしくは何らかの
基準
.Pq "例えば、基準を週 1 回にする"
からの差分だけでなく、
それらの存在そのものを報告するものです。
.Sq nosuid
オプションを
fstab/mount で指定することで、あるファイルシステム上の suid/sgid
バイナリの実行機能をオフにすることができますが、root によるこれらの
実行をオフにすることはできません。さらに、root 権限を破った者は誰でも
自分自身で用意したバイナリをインストールすることだってできます。
しかしながら、ユーザのディスク空間を大量に持つ場合、
ユーザパーティションで suid バイナリとデバイス
.Po
.Sq nodev
オプション
.Pc
を不許可にしておき、スキャンしないで済ませることも有益かもしれません。
それでも、私ならば、少なくとも週に 1 回はスキャンする
でしょう。というのは、タマネギのこの層の目的は侵入の検知だからです。
.Pp
Process accounting (see accton(1)) is a relatively low-overhead feature of
the operating system which I recommend using as a post-break-in evaluation
mechanism. It is especially useful in tracking down how an intruder has
actually broken root on a system, assuming the file is still intact after
the break-in occurs.
プロセスアカウンティング
.Po
.Xr accton 1
参照
.Pc
は、侵入後の評価の仕組みとして利用をお勧めする、
比較的オーバヘッドの低いオペレーティングシステムの機能です。
侵入を受けた後でも当該ファイルが無傷であるとするなら、
侵入者が実際のところどのようにしてシステムの root を破ったかを
追跡するのに際して特に有益です。
.Pp
Finally, security scripts should process the log files and the logs themselves
should be generated in as secured a manner as possible - remote syslog can be
very useful. An intruder tries to cover his tracks, and log files are critical
to the sysadmin trying to track down the time and method of the initial break-in.
.Sh PARANOIA
最後に、セキュリティスクリプトはログファイルを処理するようにして、
ログファイル自体はできるだけ安全性の高い方法で
(リモート syslog は極めて有益になり得ます)
生成するようにすべきです。侵入者は自分の侵入の痕跡を覆い隠そう
としますし、ログファイルはシステム管理者が最初の侵入の時刻と方法を
追跡してゆくために極めて重要です。
.Sh 偏執狂的方法
.Pp
A little paranoia never hurts. As a rule, a sysadmin can add any number
of security features as long as they do not effect convenience, and
can add security features that do effect convenience with some added
thought.
.Sh SPECIAL SECTION ON D.O.S. ATTACKS
多少偏執狂的になっても決して悪いことにはなりません。原則的に、
システム管理者は、便利さに影響を与えない範囲でいくつでもセキュリティ
機能を追加することができます。また、いくらか考慮した結果、便利さに
影響を与えるセキュリティ機能を追加することもできます。
.Sh サービス不能攻撃 (D.O.S attack) についての特記事項
.Pp
This section covers Denial of Service attacks. A DOS attack is typically
a packet attack. While there isn't much you can do about modern spoofed
packet attacks that saturate your network, you can generally limit the damage
by ensuring that the attacks cannot take down your servers.
このセクションではサービス不能攻撃を扱います。サービス不能攻撃は、普通は、
パケット攻撃です。ネットワークを飽和させる最先端の偽造パケット
.Pq spoofed packet
攻撃に対してシステム管理者が打てる手はそれほど多く
ありませんが、一般的に、その種の攻撃がサーバをダウンさせないことを
確実にすることで、被害を制限することはできます。
.Bl -enum -offset indent
.It
Limiting server forks
サーバの fork の制限
.It
Limiting springboard attacks (ICMP response attacks, ping broadcast, etc...)
踏み台攻撃の制限
.Pq ICMP 応答攻撃、ping broadcast など
.It
Kernel Route Cache
カーネルの経路情報のキャッシュ
.El
.Pp
A common DOS attack is against a forking server that attempts to cause the
server to eat processes, file descriptors, and memory until the machine
dies. Inetd (see inetd(8)) has several options to limit this sort of attack.
It should be noted that while it is possible to prevent a machine from going
down it is not generally possible to prevent a service from being disrupted
by the attack. Read the inetd manual page carefully and pay specific attention
to the -c, -C, and -R options. Note that spoofed-IP attacks will circumvent
the -C option to inetd, so typically a combination of options must be used.
Some standalone servers have self-fork-limitation parameters.
普通に見られるサービス不能攻撃に、fork するサーバプロセスに対する
ものがあります。これは、サーバにプロセス・ファイル記述子・メモリを
食い尽くさせて、マシンを殺そうとするものです。
inetd
.Po
.Xr inetd 8
参照
.Pc
には、この種の攻撃を制限するオプションがいくつかあります。マシンが
ダウンすることを防止することは可能ですが、この種の攻撃によりサービスが
崩壊することを防止することは一般的に可能とは限らないことに注意する必要が
あります。inetd のマニュアルページを注意深く読んで下さい。とくに、
.Fl c ,
.Fl C ,
.Fl R
オプションに注意して下さい。IP 偽造攻撃
.Pq spoofed-IP attack
は inetd の
.Fl C
オプションを出し抜くので、普通はオプションを
組み合わせて使用するべきであることに注意して下さい。スタンドアロンサーバ
のいくつかは、自己の fork 上限のパラメータを持っています。
.Pp
Sendmail has its -OMaxDaemonChildren option which tends to work much
better then trying to use sendmail's load limiting options due to the
load lag. You should specify a MaxDaemonChildren parameter when you start
sendmail high enough to handle your expected load but no so high that the
computer cannot handle that number of sendmails without falling on its face.
It is also prudent to run sendmail in queued mode (-ODeliveryMode=queued)
and to run the daemon (sendmail -bd) separate from the queue-runs
(sendmail -q15m). If you still want realtime delivery you can run the queue
at a much lower interval, such as -q1m, but be sure to specify a reasonable
MaxDaemonChildren option for that sendmail to prevent cascade failures.
sendmail には、
.Fl OMaxDaemonChildren
オプションがあります。負荷には遅れがあるので、
sendmail の負荷に限界を設けるオプションを使うよりも、
このオプションを使う方がまともに動作する可能性ははるかに高いです。
sendmail の実行を開始する際に、
.Cm MaxDaemonChildren
パラメータを設定するべきです。その値は、
通常見込まれる負荷を扱える程度に十分高いが、
それだけの数の sendmail を操作しようとすると
マシンが卒倒してしまうほどには高くないような値に設定するべきです。
sendmail をキュー処理モード
.Pq Fl ODeliveryMode=queued
で実行することや、
デーモン
.Pq Cm sendmail -bd
をキュー処理用
.Pq Cm sendmail -q15m
と別に実行することは用心深いことと言えます。それでもなおリアルタイムでの
配送を望むのであれば、
.Fl q1m
のように、キュー処理をはるかに短い時間間隔で
行なうことができます。いずれにしても、
.Cm MaxDaemonChildren
オプションに
合理的な値を確実に指定して、sendmail がなだれをうって失敗することが
ないようにして下さい。
.Pp
Syslogd can be attacked directly and it is strongly recommended that you use
the -s option whenever possible, and the -a option otherwise.
syslogd は直接攻撃される可能性があるので、可能ならば
.Fl s
オプションを用いることを強く推奨します。これができないなら、
.Fl a
オプションを使って下さい。
.Pp
You should also be fairly careful
with connect-back services such as tcpwrapper's reverse-identd, which can
be attacked directly. You generally do not want to use the reverse-ident
feature of tcpwrappers for this reason.
tcpwrapper の逆 identd などの接続返し
.Pq connect-back
を行なうサービスに
ついては十分注意を払うようにするべきです。これらは直接攻撃を食らう可能性が
あります。こういう事情があるので、tcpwrapper の逆 ident 機能を使おうとは
思わないのが一般的なところです。
.Pp
It is a very good idea to protect internal services from external access
by firewalling them off at your border routers. The idea here is to prevent
saturation attacks from outside your LAN, not so much to protect internal
services from root network-based root compromise. Always configure an exclusive
firewall, i.e. 'firewall everything *except* ports A, B, C, D, and M-Z'. This
way you can firewall off all of your low ports except for certain specific
services such as named (if you are primary for a zone), ntalkd, sendmail,
and other internet-accessible services.
If you try to configure the firewall the other
way - as an inclusive or permissive firewall, there is a good chance that you
will forget to 'close' a couple of services or that you will add a new internal
service and forget to update the firewall. You can still open up the
high-numbered port range on the firewall to allow permissive-like operation
without compromising your low ports. Also take note that FreeBSD allows you to
control the range of port numbers used for dynamic binding via the various
net.inet.ip.portrange sysctl's (sysctl -a | fgrep portrange), which can also
ease the complexity of your firewall's configuration. I usually use a normal
first/last range of 4000 to 5000, and a hiport range of 49152 to 65535, then
block everything under 4000 off in my firewall ( except for certain specific
internet-accessible ports, of course ).
境界ルータのところでファイアウォールを設けて、外部からのアクセスに対して
内部サービスを防御することは実によい考えです。この考え方は、LAN の外
からの飽和攻撃を防ぐことにあり、root からのネットワークベースの root
権限への攻撃から内部サービスを防御することに、あまり考慮を払って
いません。ファイアウォールは常に排他的に設定して下さい。つまり、
「ポート A, B, C, D と M から Z まで
.Eo *
以外
.Ec *
のすべてに防火壁を設ける」というふうにです。
このようにすることで、named
.Pq そこがゾーンのプライマリである場合 ,
ntalkd, sendmail など、インターネットにアクセスを提供するサービス
として特に指定するもの以外の、すべての低めのポートをファイアウォールで
停止することができます。ファイアウォールをこの他のやり方、つまり
包含的もしくは受容的なファイアウォールとして設定しようとする場合、
いくつかのサービスを
.Sq close
することを忘れたり、新しい内部サービスを
追加してファイアウォールの更新を忘れたりすることはよくあります。
ファイアウォールの高めの範囲のポートを開けておいて、低めのポートを
危険に晒すことなく受容的な動作を許すことができます。
.Bx Free
では、net.inet.ip.portrange への sysctl
.Pq sysctl -a \&| fgrep portrange ,
をいろいろ使用することで、
動的バインドに使用されるポート番号の範囲を制御できることを記憶にとどめて
おいて下さい。これによりファイアウォールの設定の複雑性を緩和できます。
私は、ファイアウォールに通常の範囲として、first/last が 4000 から 5000 を、
高位ポートの範囲として、49152 から 65535 を使用しています。さらに、
.Pq いくつかのインターネットアクセス可能なポートを除くのはもちろんですが
4000 より下のすべてをブロックしています。
.Pp
Another common DOS attack is called a springboard attack - to attack a server
in a manner that causes the server to generate responses which then overload
the server, the local network, or some other machine. The most common attack
of this nature is the ICMP PING BROADCAST attack. The attacker spoofed ping
packets sent to your LAN's broadcast address with the source IP address set
to the actual machine they wish to attack. If your border routers are not
configured to stomp on ping's to broadcast addresses, your LAN winds up
generating sufficient responses to the spoofed source address to saturate the
victim, especially when the attacker uses the same trick on several dozen
broadcast addresses over several dozen different networks at once. Broadcast
attacks of over a hundred and twenty megabits have been measured. A second
common springboard attack is against the ICMP error reporting system. By
constructing packets that generate ICMP error responses, an attacker can
saturate a server's incoming network and cause the server to saturate its
outgoing network with ICMP responses. This type of attack can also crash the
server by running it out of mbuf's, especially if the server cannot drain the
ICMP responses it generates fast enough. The FreeBSD kernel has a new kernel
compile option called ICMP_BANDLIM which limits the effectiveness of these
sorts of attacks. The last major class of springboard attacks is related to
certain internal inetd services such as the udp echo service. An attacker
simply spoofs a UDP packet with the source address being server A's echo port,
and the destination address being server B's echo port, where server A and B
are both on your LAN. The two servers then bounce this one packet back and
forth between each other. The attacker can overload both servers and their
LANs simply by injecting a few packets in this manner. Similar problems
exist with the internal chargen port. A competent sysadmin will turn off all
of these inetd-internal test services.
また別のありふれたサービス不能攻撃として、踏み台攻撃
.Pq springboard attack
と呼ばれるものがあります。これは、サーバが自分自身、ローカルネットワーク、
他のマシンを過負荷に追い込むような応答を生成させる方法でサーバを
攻撃します。この種の攻撃の中で最もありふれたものは、ICMP PING BROADCAST
攻撃があります。攻撃者は、実際に攻撃したいマシンのアドレスをソース
アドレスに設定した ping パケットを偽造して、対象の LAN の
ブロードキャストアドレスに対して送信します。境界にあるルータが
ブロードキャストアドレスに対する ping を握り潰すように設定されていない
場合、犠牲者を飽和させるのに十分な応答が、詐称されたソースアドレスに
対して生成され、LAN に嵐がまき起こります。攻撃者が同じトリックを
多くの異なるネットワークにまたがる多くのブロードキャスト
アドレスに対して同時に使用した場合、とくにひどいことになります。
これまでに、120 メガビット以上のブロードキャスト攻撃が観測されています。
2 番目の踏み台攻撃は、ICMP エラー報告の仕掛けを狙うものです。ICMP エラー
応答を生成するパケットを生成することにより、攻撃者はサーバの
受信ネットワークを飽和させることができ、同時に、サーバが送信
ネットワークを ICMP 応答で飽和させるようにすることができます。
mbuf を消費し尽くさせることにより、この種の攻撃でサーバを
クラッシュさせることも可能です。サーバの ICMP 応答生成が速過ぎて、
ICMP 応答を送信し尽くすことができない場合、とくにひどいことになります。
.Bx Free
カーネルには、この種の攻撃の効果を抑制する ICMP_BANDLIM と
呼ばれる新しいコンパイルオプションがあります。
3つめの主要なクラスに属す踏み台攻撃は、udp echo サービスのように
ある種の内部 inetd サービスに関連するものです。攻撃者は単に
ソースアドレスがサーバ A の echo ポートであり、ディスティネーション
アドレスがサーバ B の echo ポートであるかのように UDP パケットを
偽造します。ここでサーバ A, B はともに自分の LAN に接続されています。
この 2 つのサーバは、この一つのパケットを両者の間で互いに相手に対して
打ち返しあいます。このようにしていくつかのパケットを注入することで、
攻撃者は両方のサーバと LAN を過負荷状態にすることができます。
同様の問題が内部 chargen ポートにも存在します。有能なシステム管理者は
この手の inetd 内部テストサービスのすべてを無効にしておくものです。
.Pp
Spoofed packet attacks may also be used to overload the kernel route cache.
Refer to the net.inet.ip.rtexpire, rtminexpire, and rtmaxcache sysctl
parameters. A spoofed packet attack that uses a random source IP will cause
the kernel to generate a temporary cached route in the route table, viewable
with 'netstat -rna | fgrep W3'. These routes typically timeout in 1600
seconds or so. If the kernel detects that the cached route table has gotten
too big it will dynamically reduce the rtexpire but will never decrease it to
less then rtminexpire. There are two problems: (1) The kernel does not react
quickly enough when a lightly loaded server is suddenly attacked, and (2) The
rtminexpire is not low enough for the kernel to survive a sustained attack.
If your servers are connected to the internet via a T3 or better it may be
prudent to manually override both rtexpire and rtminexpire via sysctl(8).
Never set either parameter to zero (unless you want to crash the machine :-)).
Setting both parameters to 2 seconds should be sufficient to protect the route
table from attack.
偽造パケット攻撃は、カーネルの経路情報キャッシュに過負荷を生じさせるために
用いられることもあります。net.inet.ip.rtexpire, rtminexpire, rtmaxcache
の sysctl パラメータを参照して下さい。でたらめなソース IP を用いた
この偽造パケット攻撃により、カーネルは、一時的なキャッシュ経路を
経路情報テーブルに生成します。これは
.Sq netstat -rna \&| fgrep W3
で見ることができます。これらの経路は、普通は 1600 秒程度でタイムアウトに
なります。カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを
検知すると、カーネルは動的に rtexpire を減らしますが、rtminexpire より
小さくなるようには決して減らしません。ここに問題が 2 つあります。
(1) 負荷の軽いサーバが突然攻撃された場合、カーネルが十分素早く反応
しないこと。(2) カーネルが攻撃に耐え生き延びられるほど十分
rtminexpire が低くなっていないこと。自分のサーバが T3 もしくはそれより
良質の回線でインターネットに接続されている場合、
.Xr sysctl 8
を用いて rtexpire と rtminexpire とを手動で上書きしておくことが思慮深いこと
といえます。
.Pq 自分のマシンをクラッシュさせたくない限りは:-
どちらかを 0 に
するようなことは決してしないで下さい。両パラメータを 2 秒に設定すれば、
攻撃から経路情報テーブルを守るには十分でしょう。
.Sh SEE ALSO
.Sh 関連項目
.Pp
.Xr accton 1 ,
.Xr chflags 1 ,
@ -440,8 +623,12 @@ table from attack.
.Xr syslogd 1 ,
.Xr xdm 1 ,
.Xr sysctl 8
.Sh HISTORY
The
.Sh 歴史
.Nm
manual page was originally written by Matthew Dillon and first appeared
in FreeBSD-3.0.1, December 1998.
マニュアルページは、もともと
.An Matthew Dillon
によって書かれました。
最初に現れたのは、
.Bx Free -3.0.1
で 1998 年 12 月のことです。
.\" translated by Norihiro Kumagai, 98-12-29

61
ja/man/man8/pam.8
View file

@ -1,7 +1,7 @@
.\" Hey Emacs! This file is -*- nroff -*- source.
.\" %Id: pam.8,v 1.2 1997/02/15 18:37:27 morgan Exp %
.\" Copyright (c) Andrew G. Morgan 1996-7 <morgan@linux.kernel.org>
.\" jpman %Id: pam.8,v 1.2 1999/02/10 12:44:48 horikawa Chk %
.\" jpman %Id: pam.8,v 1.3 1999/02/11 09:24:24 kuma Stab %
.TH PAM 8 "1997 Feb 9" "PAM 0.56" "PAM Manual"
.SH 名称
@ -23,16 +23,18 @@ PAM \-
.BR PAM
は、システム上でアプリケーション (サービス) の認証作業を行う
ライブラリシステムです。
本ライブラリが提供する
本ライブラリは、
一般的な不変のインタフェース
(アプリケーションプログラミングインタフェース - API) は、
(アプリケーションプログラミングインタフェース - API) を提供します。
.RB ( login "(1) "
や
.BR su "(1)) "
のような特権許可プログラムの標準の認証作業の実行を遅らせます。
.BR su "(1) のような) "
特権許可プログラム
がこの API に従うことで、
標準の認証作業を遂行するようになります。
.sp
PAM アプローチの基本機能は、認証の種類を動的に設定可能とすることです。
PAM アプローチの基本的な特徴は、認証作業の性質を動的に設定可能とすることです。
言い換えると、個々のサービス提供アプリケーションがユーザを認証する方法を、
システム管理者は自由に選択できます。
この動的設定は、単一の
@ -71,20 +73,22 @@ PAM
.sp
簡単に言うと、これらのグループは、
制限されたサービスに対する典型的なユーザ要求の異なった側面の面倒をみています。
それぞれ、
ある制限されたサービスに対する典型的なユーザ要求が持つ、異なった側面の
面倒をみています。
.sp
.BR account " - "
アカウント証明型のサービスを提供します。
「ユーザのパスワードが無効になったか？」
「このユーザが要求するサービスにアクセスを許されているか？」
「ユーザのパスワードが期限切れになったか？」
「このユーザは、要求するサービスにアクセスを許されているか？」
といった事柄を扱います。
.br
.BR auth "entication - "
ユーザが名乗っている人物であることを確定します。
典型的には、ユーザが満すべき「挑戦 - 応答」の要求で実現されます。
例えば「あなたが名乗っているその人であるなら、
ユーザが名乗っている人物本人であることを確定します。
この確定は、通常は、ユーザが満すべき「挑戦 - 応答」の要求で実現されます。
例えば「あなたが名乗っているその人本人であるなら、
あなたのパスワードを入力してください。」が該当します。
全部の認証がこの型であるわけではなく、
(スマートカードや生物測定学デバイスなどを使用する)
@ -98,11 +102,11 @@ PAM
.br
.BR password " - "
このグループの責任は、認証機構を更新することです。
典型的には、このようなサービスは
このようなサービスは
.BR auth
グループのサービスと強力な結び付きがあります。
グループのサービスと強く結び付いているのが普通です。
認証機構によっては、自己の更新をこの機能に任せているものがあります。
標準の UN*X のパスワードベースのアクセスは、明かな例です。
標準の UN*X のパスワードベースのアクセスは、明らかな例です。
「代わりのパスワードを入力してください。」がこれに該当します。
.br
@ -110,8 +114,9 @@ PAM
このグループの仕事は、サービス提供の前後に実行されるべきことをカバーします。
このような作業には、認証記録の維持と、
ユーザのホームディレクトリのマウントが含まれます。
開始時と終了時にモジュールへのフックを提供することにより、
ユーザが利用可能なサービスに影響を与えますので、
開始時と終了時に
ユーザが利用可能なサービスに影響を与える
モジュールへのフックを提供するので、
.BR session
管理グループは重要です。
@ -128,17 +133,17 @@ PAM
.BR /etc/pam.d/
ディレクトリの内容であることもあります。
これらのファイルは、サービスが要求する認証作業を行う
これらのファイルは、このサービスが要求する認証作業を行う
.BR PAM
と、個々の
の一覧と、個々の
.BR PAM
が失敗したときの PAM-API の適切な動作をリストします。
が失敗したときの PAM-API の適切な動作の一覧をリストします。
.sp
.B /etc/pam.conf
設定ファイルの文法は次の通りです。
ファイルはルールのリストから構成されます。
個々のルールは典型的には単一行ですが、
個々のルールは普通は単一行ですが、
`\\<LF>' で行末をエスケープすることで複数行に渡ることが可能です。
コメントは、前に `#' マークを置き、行末まで続きます。
@ -171,12 +176,12 @@ PAM
.sp
.BR service
は、典型的には対応するアプリケーションの親しみのある名前です。
は、普通は、対応するアプリケーションの親しみのある名前です。
.BR login
や
.BR su
は良い例です。
.BR service " の名前 " other
.BR service " 名 " other
は
.I デフォルト
ルールを与えるために予約されています。
@ -187,8 +192,8 @@ PAM
.sp
.BR type
は、ルールが対応する管理グループです。
後続するモジュールがどの管理グループに関連付けられるべきかを
は、そのルールに対応する管理グループです。
後続するモジュールをどの管理グループに関連付けるべきかを
指定するために使用されます。
有効なエントリは
.BR account "; "
@ -206,14 +211,14 @@ PAM
.BR control
の値は次の通りです。
.BR requisite
- この PAM が失敗すると、認証処理は即時停止します;
- この PAM が失敗すると、認証処理は即ちに終了します;
.BR required
- この PAM が失敗すると、究極的には PAM-API は失敗を返しますが、
それはこの
.RB "(" service
および
.BR type
の) 積み重なっているモジュールの残りを起動した後です;
の) 積み重なっているモジュールの残りが呼び出されたあとです;
.BR sufficient
- この種のモジュールが成功すると、
モジュールの積み重ねの認証条件を満します
@ -261,7 +266,7 @@ PAM
.SH 準拠
DCE-RFC 86.0, October 1995.
.br
現在 DCE-RFC 委員会で考察されている追加機能があります。
現在 DCE-RFC 委員会で検討されている追加機能も含まれています。
.SH バグ
.sp 2

6
ja/man/man8/usbdevs.8
View file

@ -1,6 +1,6 @@
.\" %NetBSD: usbdevs.8,v 1.3 1998/07/23 13:57:51 augustss Exp %
.\" FreeBSD %Id: usbdevs.8,v 1.2 1998/12/14 09:40:15 n_hibma Exp %
.\" jpman %Id: usbdevs.8,v 1.4 1999/02/11 07:49:20 horikawa Stab %
.\" jpman %Id: usbdevs.8,v 1.5 1999/02/11 16:53:58 horikawa Stab %
.\" Copyright (c) 1998 The NetBSD Foundation, Inc.
.\" All rights reserved.
.\"
@ -47,8 +47,8 @@
.Op Fl v
.Sh 解説
.Nm
は、システムに接続されているすべての USB 機器を、
それぞれの機器に関する多少の情報と共に表示します。
は、システムに接続されているすべての USB 機器の一覧を、
それぞれの機器に関するいくらかの情報とともに表示します。
各行のインデントは root からの距離を示しています。
.Pp
オプションは次の通りです:

151
ja_JP.eucJP/man/man5/isdnd.rc.5
View file

@ -23,7 +23,7 @@
.\" SUCH DAMAGE.
.\"
.\" %Id: isdnd.rc.5,v 1.1 1998/12/27 21:47:01 phk Exp %
.\" jpman %Id: isdnd.rc.5,v 1.2 1999/01/24 06:59:47 horikawa Chk %
.\" jpman %Id: isdnd.rc.5,v 1.4 1999/02/11 15:43:12 horikawa Stab %
.\"
.\" last edit-date: [Sat Dec 5 18:10:08 1998]
.\"
@ -44,7 +44,7 @@ ISDN
.Pp
設定ファイルには、第 1 桁から始まるキーワードが複数含まれます。
キーワードの後には、1 個以上の空白・タブ、単一の等号、1 個以上の空白・タブ、
キーワード依存のパラメータ値が続きます。
キーワード依存のパラメータ値と続きます。
.Pp
文字 '#' で開始する行はコメント行として扱われます。
.Pp
@ -175,9 +175,9 @@ ISDN
.It Li regexpr
本キーワードは、正規表現を指定するために使用されます。
1 度より多く指定することが可能であり、
コンパイル時に依存する値まで指定可能です
(現在、ソースにおける MAX_RE の定義により、5 に設定されます)。
1 度以上、コンパイル時依存の回数
(現在、ソースにおける MAX_RE の定義では 5 回)
まで指定することが可能です。
.Pp
指定した全正規表現は実行時にログ文字列と比較され、
マッチした場合には、ログテキストをパラメータとしてプログラムが実行されます
@ -209,7 +209,7 @@ ISDN
.It Li rtprio
.Nm isdnd
が実行されるリアルタイム優先度を、整数値範囲 0 ～ 31 で指定します。
が実行されるリアルタイム優先度を、0 ～ 31 の範囲の整数値で指定します。
0 は最高の優先度です。
本キーワードは省略可能です。
指定しない場合、
@ -237,7 +237,7 @@ ISDN
.Bl -tag -width unitlengthsrc -compact
.It Li answerprog
本キーワードは、内向き電話接続が設定エントリにおいて
本キーワードは、着信電話接続が設定エントリにおいて
.Em answer
を指定した場合に実行される、プログラムの名前を指定するために使用されます。
デフォルト名は
@ -251,11 +251,11 @@ ISDN
(省略可能)
.It Li alert
呼び出しを受け付ける前に待つ秒数を指定するために使用します。
本キーワードは、内向き電話呼び出し (dialin-reaction = answer)
呼 (call) を受け付ける前に待つ秒数を指定するために使用します。
本キーワードは、電話着呼 (dialin-reaction = answer)
のためにのみ指定可能です。
応答マシンが実行を開始する前に、
電話の内向き呼び出しを受け付ける機会を持つために、使用します。
留守番マシンが実行を開始する前に、
電話の着呼 (incoming call) を受け付ける機会を持つために使用します。
本パラメータの最小値は 5 秒であり、パラメータの最大値は 180 秒です。
(省略可能)
@ -272,30 +272,30 @@ HDLC
.El
.It Li callbackwait
リモートサイトからの呼び出しをハングアップしてから
リモートサイトからの呼を切ってから
リモートサイトにコールバックするまでに待つ秒数です。(省略可能)
.It Li calledbackwait
ローカルサイトからリモートサイトを呼び出してから
ローカルサイトがリモートサイトを呼び出した後、
リモートサイトがローカルサイトにコールバックするまでに待つ秒数です。(省略可能)
.It Li dialin-reaction
内向きの接続要求を受け付けた場合にどうするかを指定するために使用します。
着信接続要求を受けた場合にどうするかを指定するために使用します。
本キーワードは必須です。
現在サポートされているパラメータは次の通りです:
.Pp
.Bl -tag -width calledback -compact -offset
.It Ar accept
内向き呼び出しを受け付けます。
着呼を受け付けます。
.It Ar reject
内向き呼び出しを拒否します。
着呼を拒否します。
.It Ar ignore
内向き呼び出しを無視します。
着呼を無視します。
.It Ar answer
内向き音声呼び出しに対して、電話応答を開始します。
着信音声呼び出しに対して、留守番電話を開始します。
.It Ar callback
リモートサイトが呼び出したとき、
ハングアップしてリモートサイトにコールバックします。
その呼を切ってリモートサイトにコールバックします。
.El
.It Li dialout-type
@ -305,10 +305,10 @@ HDLC
.Pp
.Bl -tag -width Ds -compact -offset
.It Ar normal
通常動作。呼び出しを受け付けると思われるリモートサイトを呼び出します。
通常動作。呼を受け付けると思われるリモートサイトを呼び出します。
.It Ar calledback
コールバック動作。
呼び出しを拒否してから当方にコールバックするリモートサイトを呼び出します。
呼を拒否してから当方にコールバックするリモートサイトを呼び出します。
.El
.It Li dialrandincr
@ -321,10 +321,10 @@ HDLC
最小化します。
.It Li dialretries
ダイヤルを諦める前に再試行する回数です。(省略可能)
ダイヤルをあきらめる前に再試行する回数です。(省略可能)
.It Li direction
本キーワードは、内外向き・内向きのみ・外向きのみのいずれの接続が可能であるかを
本キーワードは、発信着信・発信のみ・着信のみのいずれの接続が可能であるかを
設定するために使用します。
本キーワードは省略可能であり、デフォルトは
.Em inout
@ -336,14 +336,14 @@ HDLC
.It Ar inout
通常動作。接続の確立は、リモートからでもローカルからでも可能です。
.It Ar in
内向き接続のみ可能です。
着信接続のみ可能です。
.It Ar out
外向き接続のみ可能です。
発信接続のみ可能です。
.El
.It Li downtries
失敗する試行回数を指定するために使用します。
失敗する試行 (=再試行サイクルです!) をこの回数だけ行った後、
試行 (=再試行サイクルです!) がこの回数だけ失敗すると、
インタフェースを (
.Em downtime
秒だけ) 無効にします。
@ -355,39 +355,40 @@ HDLC
.Em downtries
の設定値の回数の後、
インタフェースが無効化される秒数を設定するために使用されます。
(前述のキーワード
(詳細はキーワード
.Em usedown
も参照)。
を参照)。
本キーワードは省略可能であり、デフォルトで 60 秒に設定されます。
.It Li earlyhangup
次の課金単位となる前にハングアップさせるための (保険の) 秒数を指定します。
次の課金単位となる前に接続を切るための (保険の) 秒数を指定します。
(省略可能)
.It Li idletime-outgoing
ハングアップ前に外向き接続がアイドルとなる秒数。(省略可能)
接続を切る前に発呼 (outgoing call) がアイドルとなる秒数。(省略可能)
.It Li idletime-incoming
ハングアップ前に内向き接続がアイドルとなる秒数。(省略可能)
接続を切る前に着呼がアイドルとなる秒数。(省略可能)
.It Li isdncontroller
本エントリの接続に対して使用される ISDN 制御番号。(必須)
本エントリの接続に使用される ISDN コントローラ番号。(必須)
.It Li isdnchannel
本エントリの接続に対して使用される ISDN 制御チャネル番号。
ここで明示的にチャネルを選択すると SETUP メッセージは本チャネルを要求しますが、
本エントリの接続に対して使用される ISDN コントローラチャネル番号。
ここで明示的にチャネルを選択すると
SETUP メッセージはそのチャネルを要求しますが、
リクエストに
.Em 好ましい
(本チャネルを好む) とマークするだけであって、
排他的 (本チャネルのみ受け付けることを意味する) とマークするのではありません。
.Em 望ましい (preferred)
(指定チャネルを望む) とマークするだけであって、
排他的 (指定チャネルのみ受け付ける) とマークするのではありません。
よって、交換局は要求されたチャネル以外を選択することが依然として可能です!
(必須)
.It Li isdntxdel-incoming
.Em timeout()
カーネルサブルーチンに適合する遅延値であり、
.Em 内向き
ISDN 接続に対して接続が成功裏に確立した後に、
.Em 着信
ISDN 接続に対して接続確立が成功した後に、
最初のパケットの送出をこの値だけ遅延させます。
指定単位は 1/100 秒です。
ゼロ (0) を指定すると本機能を無効化します。これがデフォルト値です。
@ -399,14 +400,14 @@ IP over raw HDLC ISDN
.It Li isdntxdel-outgoing
.Em timeout()
カーネルサブルーチンに適合する遅延値であり、
.Em 外向き
ISDN 接続に対して接続が成功裏に確立した後に、
.Em 発信
ISDN 接続に対して接続確立が成功した後に、
最初のパケットの送出をこの値だけ遅延させます。
指定単位は 1/100 秒です。
ゼロ (0) を指定すると本機能を無効化します。これがデフォルト値です。
本機能は
.Xr i4bipr 4
IP over raw HDLC ISDN 用に実装されました
IP over raw HDLC ISDN ドライバ用に実装されました
(本ドライバに対してのみ意味を持ちます)。(省略可能)
.It Li local-phone-dialout
@ -416,12 +417,12 @@ IP over raw HDLC ISDN
.Em "発番号情報要素 (Calling Party Number Information Element)"
に埋め込まれます。
.Pp
本キーワードは、ipr ユーザランドインタフェース用のために必須です。
本キーワードは、ipr ユーザランドインタフェースのために必須です。
.\" 原文の .em (Execute Macro) は、引数無しの場合効果が無いので削除
.\" horikawa@jp.freebsd.org 1999/01/19
.It Li local-phone-incoming
内向き呼び出しの宛先を確認するために使用する、ローカルの電話番号です。
着呼の宛先を確認するために使用する、ローカルの電話番号です。
リモートサイトがダイヤルインするとき、
リモートサイトの希望接続先がローカルサイトであることを確認するために、
本番号を使用します。
@ -432,9 +433,9 @@ IP over raw HDLC ISDN
本キーワードは ipr インタフェースのために必須です。
.It Li name
本設定エントリにシンボルによる名前を定義します。
その設定エントリにシンボルによる名前を定義します。
全画面表示においてこの名前を使用して
リモートサイトへのリンクを識別し易くすることと、
リモートサイトへのリンクを識別しやすくすることと、
アカウンティングに使用することを目的としています。(必須)
.It Li ratetype
@ -443,24 +444,24 @@ IP over raw HDLC ISDN
例えば、
ratetype=0 は /etc/isdn/isdnd.rates 中で "ra0" で開始する行を選択します
(典型的には ra0 行は、
各曜日および各時刻における、ローカル呼び出し料金の表集合です。)
各曜日および各時刻における、ローカルの呼び出し料金の表集合です。)
.It Li recoverytime
ダイヤル再試行とダイヤル再試行の間に待つ秒数。(省略可能)
.It Li remdial-handling
複数個の外向き番号が指定された場合のダイヤルアウト動作を指定するために
複数個の発信番号が指定された場合のダイヤルアウト動作を指定するために
使用されます。
現在サポートされているパラメータは次の通りです:
.Pp
.Bl -tag -width Ds -compact -offset
.It Ar first
新規 (非再試行) 呼び出しセットアップの度に、最初の番号から開始します。
新規 (非再試行) 呼設定 (call setup) の度に、最初の番号から開始します。
.It Ar last
新規 (非再試行) 呼び出しセットアップの度に、
成功裏に接続を確立できた最後の番号から開始します。
新規 (非再試行) 呼設定の度に、
接続確立が成功した最後の番号から開始します。
.It Ar next
新規 (非再試行) 呼び出しセットアップの度に、
新規 (非再試行) 呼設定の度に、
最後に使用したものの次の番号から開始します。
.El
@ -471,14 +472,14 @@ ratetype=0
.Em "着番号情報要素 (Called Party Number Information Element)"
に埋め込まれます。
.Pp
本キーワードは、ipr インタフェース用のために必須です。
本キーワードは、ipr インタフェースのために必須です。
.\" 原文の .em (Execute Macro) は、引数無しの場合効果が無いので削除
.\" horikawa@jp.freebsd.org 1999/01/19
どれかひとつが成功するまでいくつかの番号に対して試行させるために、
複数回指定可能です。
複数回指定して、
どれかひとつが成功するまでいくつかの番号に対して試行させることもできます。
.It Li remote-phone-incoming
内向き呼び出しを確認するために使用する、リモートの電話番号です。
着呼を確認するために使用する、リモートの電話番号です。
リモートサイトがダイヤルインするとき、
ローカルシステムに対して接続する権限がある
正しいリモートサイトであることを確認するために、
@ -489,12 +490,12 @@ ratetype=0
.Pp
本キーワードは ipr インタフェースのために必須です。
.Pp
本キーワードを、ワイルドカードパラメータ '*' として、
本キーワードにワイルドカードパラメータ '*' を渡して、
誰もがダイヤルイン可能とできます。
.It Li unitlength
秒数による課金単位の長さ。
アイドルタイムとともに使用して、接続をいつハングアップするのかを決定します。
アイドル時間とともに使用して、いつ接続を切るのかを決定します。
(省略可能)
.It Li unitlengthsrc
@ -515,11 +516,11 @@ unitlength
.It Ar rate
設定ファイルにおいてキーワード
.Em ratetype
で指定される料金ファイル中で指定される unitlength を使用します。
で指定される料金ファイル中の unitlength を使用します。
.It Ar aocd
ISDN 回線において AOCD を申し込んでいる場合、
動的に計算される unitlength を使用します。
(AOCD は ```Advice Of Charge During the call (呼び出し中の課金アドバイス)''
(AOCD は ```Advice Of Charge During the call (呼の間の課金アドバイス)''
の頭文字で、遠距離通信 (すなわち電話) 業者が提供する、
課金単位を示すサービスです)。
.El
@ -556,9 +557,9 @@ usrdevicename
.Em downtries
と
.Em downtime
を使用可能とするために使用します。
を有効にするために使用します。
(回線ビジーの場合等) 遷移に失敗する場合に、
過度のダイヤルアクティビティを避けるために、
過度のダイヤル動作を避けるために、
.Nm isdnd
が IP インタフェースの有効・無効を動的に切り替えるために使用します。
本パラメータは省略可能であり、デフォルトで
@ -589,43 +590,43 @@ usrdevicename
.Sh アイドル時間の計算とショートホールドモード
.Bl -tag -width incoming calls -compact
.It Li 内向き呼び出し
呼び出し側が課金構造のほとんどを知っているものと見倣すので、キーワード
.It Li 着呼
呼び出し側が課金構造などのほとんどを知っているものと見なすので、キーワード
.Em idletime-incoming
のみが内向き呼び出しに機能します。
のみが着呼に機能します。
.Pp
内向き呼び出しに対しては回線は定常的に監視され、
着呼に対しては回線は定常的に監視され、
.Em idletime-incoming
で指定する秒数の期間トラフィックが無い場合には、呼び出しは閉じられます。
で指定する秒数の期間トラフィックが無い場合には、呼は閉じられます。
.Pp
典型的には、
.Em idletime-incoming
は最終手段として使用するため、課金単位時間よりもずっと大きな値を設定します。
典型的な値は 1 ～ 5 分です。
.It Li 外向き呼び出し
外向き呼び出しの切断時間を、2 種類の方法のいずれかに設定可能です:
.It Li 発呼
発呼の切断時間を、2 種類の方法のいずれかに設定可能です:
.Bl -tag -width shorthold mode -compact
.It Li 単純モード
単純なモードであり、
.Em unitlength
は 0 (ゼロ) であり
の選択値は 0 (ゼロ) であり
.Em idletime-outgoing
は 0 より大きいことが必要です。
.Pp
外向きのトラフィクは定常的に監視され、
送信のトラフィックは定常的に監視され、
.Em idletime-outgoing
で指定された秒数だけトラフィックが無かった場合、呼び出しは閉じられます。
で指定された秒数だけトラフィックが無かった場合、呼は閉じられます。
.Pp
単純なモードの典型値は 10 ～ 30 秒です。
.It Li ショートホールドモード
ショートホールドモードでは、選択された
ショートホールドモードでは、
.Em unitlength
と
.Em idletime-outgoing
は 0 (ゼロ) より大きいことが必要であり、
の選択値は 0 (ゼロ) より大きいことが必要であり、
.Em earlyhangup は 0 (ゼロ) 以上であることが必要です
。
@ -647,7 +648,7 @@ usrdevicename
回線にトラフィックが無いかチェックされます。
チェックウィンドウ (check-window) の期間にトラフィックが検出された場合、
次の単位 (unit) の先頭から同じ手続きが再度開始されます。
チェックウィンドウ (check-window) の期間トラフィックが検出されない場合、
チェックウィンドウの期間トラフィックが検出されない場合、
チェックウィンドウ終了時に回線が閉じられます、
.Pp
注釈:

919
ja_JP.eucJP/man/man7/security.7
View file

@ -3,432 +3,615 @@
.\" the source tree.
.\"
.\" %Id: security.7,v 1.4 1998/12/26 05:19:42 dillon Exp %
.\" jpman %Id: security.7,v 1.2 1999/01/31 11:05:10 horikawa Chk %
.\" jpman %Id: security.7,v 1.3 1999/02/11 11:18:48 vanitas Stab %
.\"
.Dd December 20, 1998
.Dt SECURITY 7
.Os
.Sh NAME
.Sh 名称
.Nm security
.Nd introduction to security under FreeBSD
.Sh DESCRIPTION
.Nd FreeBSD におけるセキュリティ入門
.Sh 解説
.Pp
Security is a function that begins and ends with the system administrator.
While all
セキュリティは、システム管理者とともに始まり、システム管理者と
ともに終る機能です。すべての
.Bx
systems are inherently multi-user capable, the job of building and
maintaining security mechanisms to keep those users 'honest' is probably
one of the single largest undertakings of the sysadmin. Machines are
only as secure as you make them, and security concerns are ever competing
with the human necessity for convenience. UNIX systems,
in general, are capable of running a huge number of simultaneous processes
and many of these processes operate as servers - meaning that external entities
can connect and talk to them. As yesterday's mini-computers and mainframes
become today's desktops, and as computers become networked and internetworked,
security becomes an ever bigger issue.
システムは昔からマルチユーザに対応しています。セキュリティの仕組みを
組み込んで維持することで、ユーザを
.Sq 正直に
し続ける仕事は、システム管理者の最も大きな責務の一つでしょう。マシンは、
管理者が設定しただけのセキュリティしか示しません。セキュリティに関する
問題は、むしろ、便利さを求める人間との競合問題です。一般に、
.Ux
システムは莫大な数のプロセスを同時に実行させることも、また、その多くを
サーバとして動作させることもできます。これは、外部の何者かが
接続してきて、サーバプロセスと会話することができるということを
意味します。昨日までのミニコンピュータとメインフレームは、今日では
デスクトップコンピュータとなり、かつ、それらはネットワークで結ばれて
インターネットと接続されるようになりました。これにより、セキュリティは
昔と比べてはるかに大きな問題となっています。
.Pp
Security concerns can be split up into several categories:
セキュリティに関する問題は、いくつかのカテゴリに分類することができます。
.Bl -enum -offset indent
.It
Denial of service attacks
サービス不能攻撃
.It
User account compromises
ユーザアカウントにかかる危険
.It
Root compromise through accessible servers
アクセス可能なサーバを経由した root 権限にかかる危険
.It
Root compromise via user accounts
ユーザアカウントを通した root 権限にかかる危険
.El
.Pp
A denial of service attack is an action that deprives the machine of needed
resources. Typically, D.O.S. attacks are brute-force mechanisms that attempt
to crash or otherwise make a machine unusable by overwhelming its servers or
network stack. Some D.O.S. attacks try to take advantages of bugs in the
networking stack to crash a machine with a single packet. The latter can
only be fixed by applying a bug fix to the kernel. Attacks on servers can
often be fixed by properly specifying options to servers to limit the load
they incur on the system under adverse conditions. Brute-force network
attacks are harder to deal with. A spoofed-packet attack, for example, is
nearly impossible to stop short of cutting your system off from the internet.
サービス不能攻撃とは、マシンから必要な資源を奪う行為です。
サービス不能攻撃は、普通は、そのマシンで実行されるサーバや
ネットワークスタックを圧倒して、マシンを使えなくしたりクラッシュさせようと
するような力任せの仕組みです。サービス不能攻撃のいくつかは、
ネットワークスタックのバグを利用して、パケット一つでマシンを
クラッシュさせようとします。後者は、
カーネルにバグ修正を施すことによってのみ修正することができます。
サーバプロセスに対する攻撃は、サーバのオプションを適切に指定して、
逆境状況のシステムにおいて、サーバプロセスが引き起こす負荷に限界を設けることで
修正することができます。これらに比べると、ネットワークへの力任せの攻撃への
対応はずっと難しくなります。たとえば、偽造パケットによる攻撃
.Pq spoof-packet attack
は、インターネットからシステムを切り離す以外の方法では、抑止することは
ほとんど不可能です。
.Pp
A user account compromise is even more common then a D.O.S. attack. Many
sysadmins still run standard telnetd, rlogind, rshd, and ftpd servers on their
machines. These servers, by default, do not operate over encrypted
connections. The result is that if you have any moderate-sized user base,
one or more of your users logging into your system from a remote location
(which is the most common and convenient way to login to a system) will
have his or her password sniffed. The attentive system admin will analyze
his remote access logs occasionally looking for suspicious source addresses
even for successful logins.
ユーザアカウントを危険に晒すことは、サービス不能攻撃よりは多少はありふれた
ものです。このご時勢でも、システム管理者の多くは、自分たちのマシンで
標準の telnetd, rlogind, rshd, ftpd サーバを実行させています。これらの
サーバは、デフォルトでは、暗号化されたコネクション上で動作していません。
その結果、抱えているユーザ数が標準的な大きさならば、リモート
.Pq そのシステムにログインするのに最も普通で便利な場所
からログインしているユーザのうち一人以上は、パスワードを覗き見られて
しまうでしょう。
システム管理者が注意深いならば、たとえログインが成功していたとしても、
リモートアクセスログをときどき解析して、疑わしいソースアドレスを探すものです。
.Pp
One must always assume that once an attacker has access to a user account,
the attacker can break root. However, the reality is that in a well secured
and maintained system, access to a user account does not necessarily give the
attacker access to root. The distinction is important because without access
to root the attacker cannot generally hide his tracks and may, at best, be
able to remove that user's files and crash the machine, but not touch anyone
else's files.
ひとたび攻撃者がユーザアカウントへのアクセス権を入手すると、攻撃者が
root の権限を破る可能性があることを仮定するべきです。しかし、
セキュリティを十分保ち、手入れの行き届いたシステムにおいては、
あるユーザアカウントへのアクセスが可能となっても、攻撃者に必ずしも
root へのアクセス権を与えるとは限らないのが現実です。この違いは重要です。
というのは、root へのアクセス権がなければ、一般的に、攻撃者は自分の
侵入の痕跡を隠蔽することができませんし、そのユーザのファイルを消して
マシンをクラッシュさせることができるのがせいぜいで、他のユーザの
ファイルには手出しできません。
.Pp
System administrators must keep in mind that there are several ways to break
root on a machine. The attacker may know the root password, the attacker
may find a bug in a root-run server and be able to break root over a network
connection to that server, or the attacker may know of a bug in an suid-root
program that allows the attacker to break root once he has broken into a
user's account.
システム管理者は、あるマシン上で root の権限を破る方法がいくつかあることを
心しておかねばなりません。攻撃者が root のパスワードを知ってしまうかも
しれません。攻撃者が root の権限で実行されるサーバのバグを見つけ、
ネットワークからそのサーバへ接続して root の権限を破ることができるかも
しれません。ひとたびユーザアカウントを破ると、ユーザアカウントから
root の権限を破ることが可能であるバグを持つ suid-root プログラムの
存在を、攻撃者は知っているかもしれません。
.Pp
Security remedies are always implemented in a multi-layered 'onion peel'
approach and can be categorized as follows:
セキュリティを改善する方法は、常に、
.Sq タマネギの皮剥き
のように
複数の層のアプローチで実装されます。これらは次のように分類できます。
.Bl -enum -offset indent
.It
Securing root and staff accounts
root とスタッフのアカウントの安全性を高める。
.It
Securing root - root-run servers and suid/sgid binaries
root の安全性を高める - root 権限のサーバと suid/sgid バイナリ。
.It
Securing user accounts
ユーザアカウントの安全性を高める。
.It
Securing the password file
パスワードファイルの安全性を高める。
.It
Securing the kernel core, raw devices, and filesystems
カーネルのコア、raw デバイス、ファイルシステムの安全性を高める。
.It
Checking file integrity: binaries, configuration files, and so forth
ファイルの完全性のチェック: バイナリ、設定ファイルなど。
.It
Paranoia
偏執狂的方法。
.El
.Sh SECURING THE ROOT ACCOUNT AND SECURING STAFF ACCOUNTS
.Sh root アカウントとスタッフアカウントの安全性を高める
.Pp
Don't bother securing staff accounts if you haven't secured the root
account. Most systems have a password assigned to the root account. The
first thing you do is assume that the password is 'always' compromised.
To secure the root account you make sure that it is not possible to login
to the root account using the root password from a random user account or
over the network. If you haven't already, configure telnetd, rlogind, and
all other servers that handle login operations to refuse root logins, period,
whether the right password is given or not. Allow direct root logins only
via the system console. The '/etc/ttys' file comes in handy here and is
secure by default on most systems, but a good sysadmin always checks to make
sure.
root のアカウントの安全性を確保しないうちからスタッフのアカウントの安全性を
うんぬんしてもしかたがありません。ほとんどのシステムでは、root アカウントに
割り当てたパスワードがひとつあります。まず最初にすべきことは、
このパスワードは
.Sq いつでも
危険に晒されていると仮定することです。root アカウントの安全性を確保する
ためには、ネットワーク越しに、あるいはどれか一般ユーザのアカウントから、
root のパスワードを使って root アカウントにログインすることが決して
できないことを確実にすることです。正しいパスワードが与えられようが
与えられまいが、telnetd, rlogind, その他ログイン処理を行なうサーバ
すべてで root でのログインを拒絶するように設定していないとするなら、
今すぐそういうふうに設定して下さい。直接 root でログインできるのは、
システムコンソールからだけにして下さい。ここで役に立つのが
.Sq /etc/ttys
ファイルです。ほとんどのシステムでは、デフォルトで安全ですが、
優れたシステム管理者は、設定がそうなっているか常にチェックを怠らない
ものです。
.Pp
Of course, as a sysadmin you have to be able to get to root, so we open up
a few holes. But we make sure these holes require additional password
verification to operate. One way to make root accessible is to add appropriate
staff accounts to the wheel group (in /etc/group). The staff members placed
in the wheel group are allowed to 'su' to root. You should never give staff
members native wheel access via their entry in the password file... put staff
in a 'staff' group or something and only add those that really need root to
the wheel group. Unfortunately the wheel mechanism still allows an intruder to
break root if the intruder has gotten hold of your password file - he need only
break the root password and the password of one of the staff accounts that
happens to be in the wheel group. So while the wheel mechanism is usable,
it isn't much safer then not having a wheel group at all.
システム管理者として、自分は root になれるようにしておかねばならないの
はもちろんですから、穴をいくつか空けておきます。しかし、それらの穴を
動作させるには、さらに追加のパスワード認証が必要であるようにして
おきます。root でアクセス可能とする方法の一つとして、
適切なスタッフアカウントを
.Pq /etc/group の
wheel グループに加えることがあります。
wheel グループに置かれたスタッフメンバには、
.Sq su
を使って root になることが許されます。スタッフメンバに、
パスワードファイルのエントリでそのまま wheel のアクセス権を
与えてはいけません。スタッフは、
.Sq staff
かその類のグループに置き、その中で本当に root になる必要がある人
だけを wheel グループに加えるようにします。残念ながら、wheel の
仕組みだけだと、侵入者がパスワードファイルを手に入れると、攻撃者が
破る必要があるのは root のパスワードか、wheel グループにたまたま属す
staff アカウントの一つのパスワードだけです。wheel の仕組みは有益
ですが、wheel グループがまったく存在しない状況と比べてそれほど
安全なわけではありません。
.Pp
An indirect way to secure the root account is to secure your staff accounts
by using an alternative login access method and *'ing out the crypted password
for the staff accounts. This way an intruder may be able to steal the password
file but will not be able to break into any staff accounts (or, indirectly,
root, even if root has a crypted password associated with it). Staff members
get into their staff accounts through a secure login mechanism such as
kerberos(1) or ssh(1) (see /usr/ports/security/ssh) using a private/public
key pair. When you use something like kerberos you generally must secure
the machines which run the kerberos servers and your desktop workstation.
When you use a public/private key pair with ssh, you must generally secure
the machine you are logging in FROM (typically your workstation), but you can
also add an additional layer of protection to the key pair by password
protecting the key pair when you create it with ssh-keygen(1). Being able
to *-out the passwords for staff accounts also guarantees that staff members
can only login through secure access methods that you have setup. You can
thus force all staff members to use secure, encrypted connections for
all their sessions which closes an important hole used by many intruders: That
of sniffing the network from an unrelated, less secure machine.
root アカウントの安全性を高める間接的な方法として、別のログインアクセス
の方法を用いて、スタッフのアカウントの暗号化パスワードを\ * にして
おくことで、スタッフのアカウントの安全性を高めるものがあります。この方法
だと、侵入者がパスワードファイルを盗むことができるかもしれませんが、
スタッフアカウントを破ることはできないでしょう。また、たとえ root が暗号化
パスワードをパスワードファイルに付けていたとしても、間接的には root
アカウントも破ることができないでしょう。
スタッフメンバがスタッフアカウントでログインする際には、
.Xr kerberos 1
や
.Xr ssh 1
.Po
.Pa /usr/ports/security/ssh
参照
.Pc
のような、公開鍵 / 秘密鍵の鍵の組を使う
安全性の高いログインの仕組みを使います。kerberos のような仕掛けを使う場合、
一般に、kerberos サーバを実行するマシンと自分のデスクトップ
ワークステーションとの安全性を確保しなければなりません。ssh で
公開鍵 / 秘密鍵の鍵の組を使う場合、一般に、ログイン元マシン
.Pq 通常は自分のワークステーション
の安全性を確保しなければなりません。ここで、
.Xr ssh-keygen 1
で鍵の組を生成する際、鍵の組をパスワードで防御することにより、
鍵の組を防護するための層を追加することもできます。スタッフアカウントの
パスワードを\ * で外すことができることにより、スタッフメンバが
管理者自身が設定した安全性の高い方法でのみログインできることも保証
できます。かくして、多くの侵入者が使う重大なセキュリティの穴
.Pq 安全性の低い無関係なマシンからネットワークを覗き見る方法
のないセッションを提供する、安全性の高い暗号化されたコネクションを
使うことを、すべてのスタッフメンバに強制することができるのです。
.Pp
The more indirect security mechanisms also assume that you are logging in
from a more restrictive server to a less restrictive server. For example,
if your main box is running all sorts of servers, your workstation shouldn't
be running any. In order for your workstation to be reasonably secure
you should run as few servers as possible, up to and including no servers
at all, and you should run a password-protected screen blanker.
Of course, given physical access to
a workstation an attacker can break any sort of security you put on it.
This is definitely a problem that you should consider but you should also
consider the fact that the vast majority of break-ins occur remotely, over
a network, from people who do not have physical access to your workstation or
servers.
より間接的なセキュリティの仕組みは、より制限の強いサーバから制限の弱い
サーバへログインすることを前提としています。例えば、主マシンで、
すべての種類のサーバを実行させている場合、ワークステーションではそれらの
サーバを実行させてはなりません。ワークステーションの安全性を比較的
高めておくためには、実行するサーバの数を、果てはサーバなしまで、
できるだけ減らしておくべきです。また、パスワード防護された
スクリーンセーバを走らせておくべきです。
ワークステーションへの物理的アクセスが与えられたとすると、攻撃者は
管理者が設定したいかなる種類のセキュリティをもうち破ることができるのは
もちろんのことです。これは、管理者として考えておかねばならない決定的な
問題ですが、システム破りの大多数は、ネットワーク経由でリモートから、
ワークステーションやサーバへの物理的アクセス手段を持たない人々によって
行なわれるという事実も、また、念頭に置いておく必要があります。
.Pp
Using something like kerberos also gives you the ability to disable or
change the password for a staff account in one place and have it immediately
effect all the machine the staff member may have an account on. If a staff
member's account gets compromised, the ability to instantly change his
password on all machines should not be underrated. With discrete passwords,
changing a password on N machines can be a mess. You can also impose
re-passwording restrictions with kerberos: not only can a kerberos ticket
be made to timeout after a while, but the kerberos system can require that
the user choose a new password after a certain period of time (say, once a
month).
.Sh SECURING ROOT - ROOT-RUN SERVERS AND SUID/SGID BINARIES
kerberos のような方法を使うことで、スタッフアカウントのパスワードの変更
もしくは停止を一箇所で行なうことと、スタッフメンバがアカウントを持つ
すべてのマシンに即時にその効果を及ぼすことが可能となります。スタッフメンバの
アカウントが危険に晒されたときに、すべてのマシンでその人のパスワードを
即座に変更する機能を甘く見てはいけません。パスワードが分散されていると、
N 台のマシンでパスワードを変更することは、てんやわんやの事態を招く可能性が
あります。kerberos による再パスワード制限
.Pq re-passwording restriction
を課することもできます。これを使うことにより可能となることは、
ある kerberos チケットをしばらくしてからタイムアウトにすることだけでなく、
kerberos システムがユーザに一定期間
.Pq 例えば、1 ヶ月に 1 回
の後に新しいパスワードを選ぶことを要求することもできます。
.Sh root の安全性を高める - root 権限のサーバと suid/sgid バイナリ
.Pp
The prudent sysadmin only runs the servers he needs to, no more, no less. Be
aware that third party servers are often the most bug-prone. For example,
running an old version of imapd or popper is like giving a universal root
ticket out to the entire world. Never run a server that you have not checked
out carefully. Many servers do not need to be run as root. For example,
the ntalk, comsat, and finger daemons can be run in special user 'sandboxes'.
A sandbox isn't perfect unless you go to a large amount of trouble, but the
onion approach to security still stands: If someone is able to break in
through a server running in a sandbox, they still have to break out of the
sandbox. The more layers the attacker must break through, the lower the
likelihood of his success. Root holes have historically been found in
virtually every server ever run as root, including basic system servers.
If you are running a machine through which people only login via sshd and
never login via telnetd or rshd or rlogind, then turn off those services!
用心深いシステム管理者は、自分に必要なサーバプロセスだけを過不足なく
実行させるものです。第三者製のサーバはしばしばバグの温床であることに
注意して下さい。例えば、古いバージョンの imapd や popper を実行させ
ておくということは、全世界に共通の root の切符を与えているようなものです。
自分で注意深くチェックしていないサーバは、決して実行してはいけません。
サーバの多くは root で実行させる必要はありません。例えば、ntalk, comsat,
finger デーモンを、特別の「砂場
.Pq sandbox
」ユーザで実行させることができます。
.\"kuma hellofalot of trouble って何や？
.\" hell of a lot of trouble みたいですね。;-) (金ん田 '99.02.11)
管理者が膨大な数の問題に直面しない限り、砂場は完璧では
ありませんが、セキュリティに関するタマネギ的アプローチはここでも
成り立ちます。砂場で実行されているサーバプロセスを経由して侵入を
果たすことができたとしても、攻撃者はさらに砂場から外に脱出しなければ
なりません。攻撃者が通過せねばならない層の数が増えれば増えるほど、
それだけ攻撃者が侵入に成功する確率が減ります。root の抜け穴は
歴史的に、基本システムサーバも含め、
root 権限で実行されるほとんどすべてのサーバプロセスに発見されています。
ユーザが sshd 経由でのみログインし、
telnetd, rshd, rlogind 経由でログインすること
が決してないマシンをお使いなら、それらのサービスを停止させて下さい。
.Pp
FreeBSD now defaults to running ntalkd, comsat, and finger in a sandbox.
Another program which may be a candidate for running in a sandbox is
named(8). The default rc.conf includes the arguments necessary to run
named in a sandbox in a commented-out form. Depending on whether you
are installing a new system or upgrading an existing system, the special
user accounts used by these sandboxes may not be installed. The prudent
sysadmin would research and implement sandboxes for servers whenever possible.
.Bx Free
では、今では ntalkd, comsat, finger は砂場で実行させることが
デフォルトになっています。次に砂場で実行させるべきプログラムの候補として、
.Xr named 8
があります。デフォルトの rc.conf ファイルには、named を砂場で実行する
ために必要な引数がコメントアウトされた形式で含められています。新しい
システムをインストールしているか、それとも既存のシステムを
アップグレードして使っているかに依存しますが、砂場として使用する
特別のユーザアカウントがインストールされていないかもしれません。用心深い
システム管理者は研究を怠らず、可能なところではつねにサーバに砂場を仕込む
ものです。
.Pp
There are a number of other servers that typically do not run in sandboxes:
sendmail, popper, imapd, ftpd, and others. There are alternatives to
some of these, but installing them may require more work then you are willing
to put (the convenience factor strikes again). You may have to run these
servers as root and rely on other mechanisms to detect break-ins that might
occur through them.
通常、砂場で実行しないサーバが他にいくつかあります。sendmail, popper,
imapd, ftpd などです。これらのうちいくつかには代わりがありますが、
代わりのものをインストールするには、それだけ多くの仕事が必要になるので、
結局これらを喜んで入れてしまいます
.Pq 簡単度がまたも勝利を収めるわけです
。
これらのサーバは、root 権限で実行せねばならず、これら経由で生じる侵入の
検出のためには、他の仕組みに依存せねばならないかもしれません。
.Pp
The other big potential root hole in a system are the suid-root and sgid
binaries installed on the system. Most of these binaries, such as rlogin,
reside in /bin, /sbin, /usr/bin, or /usr/sbin. While nothing is 100% safe,
the system-default suid and sgid binaries can be considered reasonably safe.
Still, root holes are occasionally found in these binaries. A root hole
was found in Xlib in 1998 that made xterm (which is typically suid) vulnerable.
It is better to be safe then sorry and the prudent sysadmin will restrict suid
binaries that only staff should run to a special group that only staff can
access, and get rid of (chmod 000) any suid binaries that nobody uses. A
server with no display generally does not need an xterm binary. Sgid binaries
can be almost as dangerous. If an intruder can break an sgid-kmem binary the
intruder might be able to read /dev/kmem and thus read the crypted password
file, potentially compromising any passworded account. An intruder that breaks
the tty group can write to almost user's tty. If a user is running a terminal
program or emulator with a talk-back feature, the intruder can potentially
generate a data stream that causes the user's terminal to echo a command, which
is then run as that user.
.Sh SECURING USER ACCOUNTS
システムの root 権限の潜在的な穴で他に大きなものとして、システムに
インストールされた suid-root/sgid バイナリがあります。rlogin など、
これらのバイナリのほとんどは、/bin, /sbin, /usr/bin, /usr/sbin に
存在します。100% 安全なものは存在しないとはいえ、システムデフォルトの
siud/sgid バイナリは比較的安全といえます。それでもなお、root の穴が
これらのバイナリにときおり発見されています。1998 年に Xlib で見つかった
root の穴は、xterm
.Pq 普通、suid 設定されています
を攻撃可能にしていました。
安全である方がよいので、用心深いシステム管理者は残念に思いながらも、
スタッフのみが実行する必要がある suid バイナリは、スタッフのみが
アクセス可能な特別なグループに含めるように制限を加え、
誰も使わない suid バイナリは chmod 000 して片付けてしまうでしょう。
ディスプレイを持たないサーバは、一般的に xterm のバイナリを必要としません。
sgid バイナリもほとんど同様の危険な存在になり得ます。
侵入者が sgid-kmem のバイナリを破ることができた場合、
その侵入者は /dev/kmem を読み出すことができるようになります。
つまり、暗号化されたパスワードファイルを読み出すことができる
ようになるので、パスワードを持つどのアカウントをも、
.Pq 潜在的な
危険に晒すことになります。
tty グループを破った侵入者は、ほとんどすべてのユーザの端末に書き込みが
できます。talk-back 機能を持つ端末プログラムやエミュレータをユーザが実行
していると、
.Pq 結局、そのユーザとして実行される
コマンドをユーザの端末にエコーさせるデータストリームを
侵入者が生成できる可能性があります。
.Sh ユーザアカウントの安全性を高める
.Pp
User accounts are usually the most difficult to secure. While you can impose
Draconian access restrictions on your staff and *-out their passwords, you
may not be able to do so with any general user accounts you might have. If
you do have sufficient control then you may win out and be able to secure the
user accounts properly. If not, you simply have to be more vigilant in your
monitoring of those accounts. Use of ssh and kerberos for user accounts is
more problematic, but still a very good solution compared to a crypted
password.
.Sh SECURING THE PASSWORD FILE
ユーザアカウントは、普通、安全性を高めることが最も困難です。
スタッフに対して、アテナイのドラコのような厳格なアクセス制限を課し、
スタッフのパスワードを\ * で外すことができるとはいえ、管理者が持ちうる
一般ユーザすべてのアカウントに対して同じことはできないかも知れません。
十分な管理を保つならば、管理者は勝利し、ユーザの
アカウントを適切な状態で安全を確保できるかもしれません。それが
保てないならば、一般ユーザのアカウントをモニタしていっそう気を配るように
するしかありません。一般ユーザアカウントでの ssh や kerberos の利用は、
いろいろ問題をはらんでいます。それでも、暗号化パスワードと比較すると、
はるかに良い解です。
.Sh パスワードファイルの安全性を高める
.Pp
The only sure fire way is to *-out as many passwords as you can and
use ssh or kerberos for access to those accounts. Even though the
crypted password file (/etc/spwd.db) can only be read by root, it may
be possible for a intruder to obtain read access to that file even if the
attacker cannot obtain root-write access.
できるだけ多くのパスワードを\ * で外し、それらのアカウントのアクセスには
ssh や kerberos を使うようにすることが、唯一の確実な方法です。たとえ暗号化
パスワードファイル
.Pq /etc/spwd.db
が root でのみ読み出し可能だとしても、
たとえ root の書き込み権限が得られないにしても、侵入者がそのファイルの
読み出しアクセス権限を得ることは可能かも知れません。
.Pp
Your security scripts should always check for and report changes to
the password file (see 'Checking file integrity' below).
.Sh SECURING THE KERNEL CORE, RAW DEVICES, AND FILESYSTEMS
セキュリティスクリプトは常にパスワードファイルの変更をチェックし、報告
するようにすべきです (後述の「ファイルの完全性のチェック」を参照して下さい)。
.Sh カーネルのコア、raw デバイス、ファイルシステムの安全性を高める
.Pp
If an attacker breaks root he can do just about anything, but there
are certain conveniences. For example, most modern kernels have a
packet sniffing device driver built in. Under FreeBSD it is called
the 'bpf' device. A intruder will commonly attempt to run a packet sniffer
on a compromised machine. You do not need to give the intruder the
capability and most systems should not have the bpf device compiled in.
Unfortunately, there is another kernel feature called the Loadable Kernel
Module interface. An enterprising intruder can use an LKM to install
his own bpf device or other sniffing device on a running kernel. If you
do not need to use the module loader, turn it off in the kernel configuration
with the NO_LKM option.
root の権限を破ると、攻撃者はほとんど何でもできますが、
もっと簡便なこともいくつかあります。例えば、最近のカーネルのほとんどでは、
組み込みのパケット覗き見デバイス
.Pq packet sniffing device
ドライバを備えています。
.Bx Free
では
.Sq bpf
デバイスと呼ばれています。侵入者は普通、危険に晒された
マシンでパケット覗き見プログラムを実行させようと試みます。侵入者に
わざわざそういう機能を提供する必要はないので、ほとんどのシステムで bpf
デバイスを組み込むべきではありません。不幸なことに、ローダブルカーネル
モジュール
.Pq Loadable Kernel Module:LKM
インタフェースと呼ばれる
カーネル機能があります。やる気まんまんの侵入者は、LKM を使って
自分独自の bpf もしくはその他覗き見デバイスを動作中のカーネルに
インストールすることが可能です。
モジュールローダを使う必要がないのであれば、カーネル設定で
NO_LKM オプションを設定してこの機能を無効にして下さい。
.Pp
But even if you turn off the bpf device, and turn off the module loader,
you still have /dev/mem and /dev/kmem to worry about. For that matter,
the intruder can still write raw devices. To avoid this you have to run
the kernel at a higher secure level... at least securelevel 1. The securelevel
can be set with a sysctl on the kern.securelevel variable. Once you have
set the securelevel to 1, write access to raw devices will be denied and
special chflags flags, such as 'schg', will be enforced. You must also ensure
that the 'schg' flag is set on critical startup binaries, directories, and
script files - everything that gets run up to the point where the securelevel
is set. This might be overdoing it, and upgrading the system is much more
difficult when you operate at a higher secure level. You may compromise and
run the system at a higher secure level but not set the schg flag for every
system file and directory under the sun.
.Sh CHECKING FILE INTEGRITY: BINARIES, CONFIG FILES, ETC
bpf デバイスを外し、モジュールローダを無効にしても、/dev/mem と /dev/kmem
という悩みの種がまだ残っています。この問題に関しては、侵入者は raw
デバイスに書き込むこともできます。この問題を避けるため、システム管理者は
カーネルをより高い安全レベル
.Pq securelevel
、少なくとも安全レベル 1 で実行させる必要があります。
sysctl を使って kern.securelevel 変数に安全レベルを設定することが
できます。ひとたび安全レベルに 1 を設定すると、
raw デバイスに対する書き込みアクセスは拒否され、例えば
.Sq schg
のような
特別な chflags フラグが効果を発揮します。これに加えて、
起動において重要なバイナリ・ディレクトリ・スクリプトファイルなど、
安全レベルが設定されるまでの間に実行されるものすべてに対しても
.Sq schg
フラグを確実に on にしておく必要があります。この設定をやり過ぎても
構いませんが、より高い安全レベルで動作している場合、システムの
アップグレードがはるかに困難になります。システムをより高い安全レベルで
実行させるようにするが、お天道さまの下にあるすべてのシステムファイルと
ディレクトリに schg フラグを設定しないという妥協をする方法もあります。
.Sh ファイルの完全性のチェック: バイナリ、設定ファイルなど
.Pp
When it comes right down to it, you can only protect your core system
configuration and control files so much before the convenience factor
rears its ugly head. The last layer of your security onion is perhaps
the most important - detection.
ことここに至るとシステム管理者にできることは、
便利度がその醜い頭を上げない程度に、
コアシステムの設定 / 制御ファイルを防御することだけです。
セキュリティのタマネギの最後の層はおそらく最も重要なもの、すなわち探知です。
.Pp
The only correct way to check a system's file integrity is via another,
more secure system. It is fairly easy to setup a 'secure' system: you
simply do not run any services on it. With a secure system in place you
can then give it access to other system's root spaces via ssh. This may
seem like a security breech, but you have to put your trust somewhere and
as long as you don't do something stupid like run random servers it really
is possible to build a secure machine. When I say 'secure' here, I assuming
physical access security as well, of course. Given a secure machine with
root access on all your other machines, you can then write security scripts
ON the secure machine to check the other machines on the system. The most
common way of checking is to have the security script scp(1) over a find
and md5 binary and then ssh a shell command to the remote machine to md5
all the files in the system (or, at least, the /, /var, and /usr partitions!).
The security machine copies the results to a file and diff's them against
results from a previous run (or compares the results against its own
binaries), then emails each staff member a daily report of differences.
システムファイルの完全性をチェックする唯一の正しい方法は、別の、より安全な
システム経由で行なう方法だけです。
.Sq 安全
なシステムを準備することは比較的
容易です。単に、サービスを一切実行しないようにするだけです。安全なシステム
を用いて、ssh 経由で他のシステムの root 空間にアクセスします。これは
セキュリティの末端のように見えるかもしれません。しかし、管理者には信頼を
どこかに置く必要があります。いきあたりばったりでサーバプロセスを
実行するような馬鹿げたことをしない限りは、安全度の高いマシンを構築する
ことは本当に可能です。ここで
.Sq 安全
という場合、物理アクセスに対する
セキュリティをも含めて仮定していることはもちろんです。安全なマシンで、
他のすべてのマシンに root のアクセス権限を持つものが得られると、
「安全なマシンの上で」システムの他のマシンをチェックする
セキュリティスクリプトを書くことができるようになります。
最も普通のチェック方法は、セキュリティスクリプトで、
まず、find と md5 のバイナリファイルをリモートマシンに
.Xr scp 1
してから、
リモートシステムのすべてのファイル
.Pq もしくは、少なくとも /, /var, /usr パーティション!
に対して md5 を適用するシェルコマンドを
ssh を使ってリモートマシンで実行するものです。
安全なマシンは、チェック結果をファイルにコピーし、前回のチェック結果と
diff を取り
.Pq または、安全なマシン自身のバイナリと比較する
違いを
毎日のレポートとしてスタッフメンバひとりひとりにメールを送ります。
.Pp
Another way to do this sort of check is to NFS export the major filesystems
from every other machine to the security machine. This is somewhat more
network intensive but also virtually impossible for an intruder to detect
or spoof.
この種のチェックを行なうもう一つの方法として、安全なマシンに対して、
他のマシンの主なファイルシステムを NFS export する方法があります。
このやり方はいくらかネットワークに負荷を掛けることになりますが、
侵入者がチェックを探知したり偽造したりすることは、
事実上不可能になります。
.Pp
A good security script will also check for changes to user and staff members
access configuration files: .rhosts, .shosts, .ssh/authorized_keys, and
so forth... files that might fall outside the prevue of the MD5 check.
優れたセキュリティスクリプトは、一般ユーザやスタッフメンバのアクセス制御
ファイル: .rhosts, .shosts, .ssh/authorized_keys など、MD5 での精細な
チェックから洩れそうなファイルの変更をチェックします。
.Pp
A good security script will check for suid and sgid binaries on all
filesystems and report their absolute existence as well as a diff against
the previous report or some baseline (say, make a baseline once a week).
While you can turn off the ability to run suid and sgid binaries on certain
filesystems through the 'nosuid' option in fstab/mount, you cannot turn this
off on root and anyone who breaks root can just install their binary their.
If you have a huge amount of user disk space, though, it may be useful to
disallow suid binaries and devices ('nodev' option) on the user partitions
so you do not have to scan them for such. I would scan them anyway, though,
at least once a week, since the object of this onion layer is detection of
a break-in.
優れたセキュリティスクリプトは、すべてのファイルシステム上で suid/sgid
バイナリに対してチェックを行ない、前回のチェック結果もしくは何らかの
基準
.Pq "例えば、基準を週 1 回にする"
からの差分だけでなく、
それらの存在そのものを報告するものです。
.Sq nosuid
オプションを
fstab/mount で指定することで、あるファイルシステム上の suid/sgid
バイナリの実行機能をオフにすることができますが、root によるこれらの
実行をオフにすることはできません。さらに、root 権限を破った者は誰でも
自分自身で用意したバイナリをインストールすることだってできます。
しかしながら、ユーザのディスク空間を大量に持つ場合、
ユーザパーティションで suid バイナリとデバイス
.Po
.Sq nodev
オプション
.Pc
を不許可にしておき、スキャンしないで済ませることも有益かもしれません。
それでも、私ならば、少なくとも週に 1 回はスキャンする
でしょう。というのは、タマネギのこの層の目的は侵入の検知だからです。
.Pp
Process accounting (see accton(1)) is a relatively low-overhead feature of
the operating system which I recommend using as a post-break-in evaluation
mechanism. It is especially useful in tracking down how an intruder has
actually broken root on a system, assuming the file is still intact after
the break-in occurs.
プロセスアカウンティング
.Po
.Xr accton 1
参照
.Pc
は、侵入後の評価の仕組みとして利用をお勧めする、
比較的オーバヘッドの低いオペレーティングシステムの機能です。
侵入を受けた後でも当該ファイルが無傷であるとするなら、
侵入者が実際のところどのようにしてシステムの root を破ったかを
追跡するのに際して特に有益です。
.Pp
Finally, security scripts should process the log files and the logs themselves
should be generated in as secured a manner as possible - remote syslog can be
very useful. An intruder tries to cover his tracks, and log files are critical
to the sysadmin trying to track down the time and method of the initial break-in.
.Sh PARANOIA
最後に、セキュリティスクリプトはログファイルを処理するようにして、
ログファイル自体はできるだけ安全性の高い方法で
(リモート syslog は極めて有益になり得ます)
生成するようにすべきです。侵入者は自分の侵入の痕跡を覆い隠そう
としますし、ログファイルはシステム管理者が最初の侵入の時刻と方法を
追跡してゆくために極めて重要です。
.Sh 偏執狂的方法
.Pp
A little paranoia never hurts. As a rule, a sysadmin can add any number
of security features as long as they do not effect convenience, and
can add security features that do effect convenience with some added
thought.
.Sh SPECIAL SECTION ON D.O.S. ATTACKS
多少偏執狂的になっても決して悪いことにはなりません。原則的に、
システム管理者は、便利さに影響を与えない範囲でいくつでもセキュリティ
機能を追加することができます。また、いくらか考慮した結果、便利さに
影響を与えるセキュリティ機能を追加することもできます。
.Sh サービス不能攻撃 (D.O.S attack) についての特記事項
.Pp
This section covers Denial of Service attacks. A DOS attack is typically
a packet attack. While there isn't much you can do about modern spoofed
packet attacks that saturate your network, you can generally limit the damage
by ensuring that the attacks cannot take down your servers.
このセクションではサービス不能攻撃を扱います。サービス不能攻撃は、普通は、
パケット攻撃です。ネットワークを飽和させる最先端の偽造パケット
.Pq spoofed packet
攻撃に対してシステム管理者が打てる手はそれほど多く
ありませんが、一般的に、その種の攻撃がサーバをダウンさせないことを
確実にすることで、被害を制限することはできます。
.Bl -enum -offset indent
.It
Limiting server forks
サーバの fork の制限
.It
Limiting springboard attacks (ICMP response attacks, ping broadcast, etc...)
踏み台攻撃の制限
.Pq ICMP 応答攻撃、ping broadcast など
.It
Kernel Route Cache
カーネルの経路情報のキャッシュ
.El
.Pp
A common DOS attack is against a forking server that attempts to cause the
server to eat processes, file descriptors, and memory until the machine
dies. Inetd (see inetd(8)) has several options to limit this sort of attack.
It should be noted that while it is possible to prevent a machine from going
down it is not generally possible to prevent a service from being disrupted
by the attack. Read the inetd manual page carefully and pay specific attention
to the -c, -C, and -R options. Note that spoofed-IP attacks will circumvent
the -C option to inetd, so typically a combination of options must be used.
Some standalone servers have self-fork-limitation parameters.
普通に見られるサービス不能攻撃に、fork するサーバプロセスに対する
ものがあります。これは、サーバにプロセス・ファイル記述子・メモリを
食い尽くさせて、マシンを殺そうとするものです。
inetd
.Po
.Xr inetd 8
参照
.Pc
には、この種の攻撃を制限するオプションがいくつかあります。マシンが
ダウンすることを防止することは可能ですが、この種の攻撃によりサービスが
崩壊することを防止することは一般的に可能とは限らないことに注意する必要が
あります。inetd のマニュアルページを注意深く読んで下さい。とくに、
.Fl c ,
.Fl C ,
.Fl R
オプションに注意して下さい。IP 偽造攻撃
.Pq spoofed-IP attack
は inetd の
.Fl C
オプションを出し抜くので、普通はオプションを
組み合わせて使用するべきであることに注意して下さい。スタンドアロンサーバ
のいくつかは、自己の fork 上限のパラメータを持っています。
.Pp
Sendmail has its -OMaxDaemonChildren option which tends to work much
better then trying to use sendmail's load limiting options due to the
load lag. You should specify a MaxDaemonChildren parameter when you start
sendmail high enough to handle your expected load but no so high that the
computer cannot handle that number of sendmails without falling on its face.
It is also prudent to run sendmail in queued mode (-ODeliveryMode=queued)
and to run the daemon (sendmail -bd) separate from the queue-runs
(sendmail -q15m). If you still want realtime delivery you can run the queue
at a much lower interval, such as -q1m, but be sure to specify a reasonable
MaxDaemonChildren option for that sendmail to prevent cascade failures.
sendmail には、
.Fl OMaxDaemonChildren
オプションがあります。負荷には遅れがあるので、
sendmail の負荷に限界を設けるオプションを使うよりも、
このオプションを使う方がまともに動作する可能性ははるかに高いです。
sendmail の実行を開始する際に、
.Cm MaxDaemonChildren
パラメータを設定するべきです。その値は、
通常見込まれる負荷を扱える程度に十分高いが、
それだけの数の sendmail を操作しようとすると
マシンが卒倒してしまうほどには高くないような値に設定するべきです。
sendmail をキュー処理モード
.Pq Fl ODeliveryMode=queued
で実行することや、
デーモン
.Pq Cm sendmail -bd
をキュー処理用
.Pq Cm sendmail -q15m
と別に実行することは用心深いことと言えます。それでもなおリアルタイムでの
配送を望むのであれば、
.Fl q1m
のように、キュー処理をはるかに短い時間間隔で
行なうことができます。いずれにしても、
.Cm MaxDaemonChildren
オプションに
合理的な値を確実に指定して、sendmail がなだれをうって失敗することが
ないようにして下さい。
.Pp
Syslogd can be attacked directly and it is strongly recommended that you use
the -s option whenever possible, and the -a option otherwise.
syslogd は直接攻撃される可能性があるので、可能ならば
.Fl s
オプションを用いることを強く推奨します。これができないなら、
.Fl a
オプションを使って下さい。
.Pp
You should also be fairly careful
with connect-back services such as tcpwrapper's reverse-identd, which can
be attacked directly. You generally do not want to use the reverse-ident
feature of tcpwrappers for this reason.
tcpwrapper の逆 identd などの接続返し
.Pq connect-back
を行なうサービスに
ついては十分注意を払うようにするべきです。これらは直接攻撃を食らう可能性が
あります。こういう事情があるので、tcpwrapper の逆 ident 機能を使おうとは
思わないのが一般的なところです。
.Pp
It is a very good idea to protect internal services from external access
by firewalling them off at your border routers. The idea here is to prevent
saturation attacks from outside your LAN, not so much to protect internal
services from root network-based root compromise. Always configure an exclusive
firewall, i.e. 'firewall everything *except* ports A, B, C, D, and M-Z'. This
way you can firewall off all of your low ports except for certain specific
services such as named (if you are primary for a zone), ntalkd, sendmail,
and other internet-accessible services.
If you try to configure the firewall the other
way - as an inclusive or permissive firewall, there is a good chance that you
will forget to 'close' a couple of services or that you will add a new internal
service and forget to update the firewall. You can still open up the
high-numbered port range on the firewall to allow permissive-like operation
without compromising your low ports. Also take note that FreeBSD allows you to
control the range of port numbers used for dynamic binding via the various
net.inet.ip.portrange sysctl's (sysctl -a | fgrep portrange), which can also
ease the complexity of your firewall's configuration. I usually use a normal
first/last range of 4000 to 5000, and a hiport range of 49152 to 65535, then
block everything under 4000 off in my firewall ( except for certain specific
internet-accessible ports, of course ).
境界ルータのところでファイアウォールを設けて、外部からのアクセスに対して
内部サービスを防御することは実によい考えです。この考え方は、LAN の外
からの飽和攻撃を防ぐことにあり、root からのネットワークベースの root
権限への攻撃から内部サービスを防御することに、あまり考慮を払って
いません。ファイアウォールは常に排他的に設定して下さい。つまり、
「ポート A, B, C, D と M から Z まで
.Eo *
以外
.Ec *
のすべてに防火壁を設ける」というふうにです。
このようにすることで、named
.Pq そこがゾーンのプライマリである場合 ,
ntalkd, sendmail など、インターネットにアクセスを提供するサービス
として特に指定するもの以外の、すべての低めのポートをファイアウォールで
停止することができます。ファイアウォールをこの他のやり方、つまり
包含的もしくは受容的なファイアウォールとして設定しようとする場合、
いくつかのサービスを
.Sq close
することを忘れたり、新しい内部サービスを
追加してファイアウォールの更新を忘れたりすることはよくあります。
ファイアウォールの高めの範囲のポートを開けておいて、低めのポートを
危険に晒すことなく受容的な動作を許すことができます。
.Bx Free
では、net.inet.ip.portrange への sysctl
.Pq sysctl -a \&| fgrep portrange ,
をいろいろ使用することで、
動的バインドに使用されるポート番号の範囲を制御できることを記憶にとどめて
おいて下さい。これによりファイアウォールの設定の複雑性を緩和できます。
私は、ファイアウォールに通常の範囲として、first/last が 4000 から 5000 を、
高位ポートの範囲として、49152 から 65535 を使用しています。さらに、
.Pq いくつかのインターネットアクセス可能なポートを除くのはもちろんですが
4000 より下のすべてをブロックしています。
.Pp
Another common DOS attack is called a springboard attack - to attack a server
in a manner that causes the server to generate responses which then overload
the server, the local network, or some other machine. The most common attack
of this nature is the ICMP PING BROADCAST attack. The attacker spoofed ping
packets sent to your LAN's broadcast address with the source IP address set
to the actual machine they wish to attack. If your border routers are not
configured to stomp on ping's to broadcast addresses, your LAN winds up
generating sufficient responses to the spoofed source address to saturate the
victim, especially when the attacker uses the same trick on several dozen
broadcast addresses over several dozen different networks at once. Broadcast
attacks of over a hundred and twenty megabits have been measured. A second
common springboard attack is against the ICMP error reporting system. By
constructing packets that generate ICMP error responses, an attacker can
saturate a server's incoming network and cause the server to saturate its
outgoing network with ICMP responses. This type of attack can also crash the
server by running it out of mbuf's, especially if the server cannot drain the
ICMP responses it generates fast enough. The FreeBSD kernel has a new kernel
compile option called ICMP_BANDLIM which limits the effectiveness of these
sorts of attacks. The last major class of springboard attacks is related to
certain internal inetd services such as the udp echo service. An attacker
simply spoofs a UDP packet with the source address being server A's echo port,
and the destination address being server B's echo port, where server A and B
are both on your LAN. The two servers then bounce this one packet back and
forth between each other. The attacker can overload both servers and their
LANs simply by injecting a few packets in this manner. Similar problems
exist with the internal chargen port. A competent sysadmin will turn off all
of these inetd-internal test services.
また別のありふれたサービス不能攻撃として、踏み台攻撃
.Pq springboard attack
と呼ばれるものがあります。これは、サーバが自分自身、ローカルネットワーク、
他のマシンを過負荷に追い込むような応答を生成させる方法でサーバを
攻撃します。この種の攻撃の中で最もありふれたものは、ICMP PING BROADCAST
攻撃があります。攻撃者は、実際に攻撃したいマシンのアドレスをソース
アドレスに設定した ping パケットを偽造して、対象の LAN の
ブロードキャストアドレスに対して送信します。境界にあるルータが
ブロードキャストアドレスに対する ping を握り潰すように設定されていない
場合、犠牲者を飽和させるのに十分な応答が、詐称されたソースアドレスに
対して生成され、LAN に嵐がまき起こります。攻撃者が同じトリックを
多くの異なるネットワークにまたがる多くのブロードキャスト
アドレスに対して同時に使用した場合、とくにひどいことになります。
これまでに、120 メガビット以上のブロードキャスト攻撃が観測されています。
2 番目の踏み台攻撃は、ICMP エラー報告の仕掛けを狙うものです。ICMP エラー
応答を生成するパケットを生成することにより、攻撃者はサーバの
受信ネットワークを飽和させることができ、同時に、サーバが送信
ネットワークを ICMP 応答で飽和させるようにすることができます。
mbuf を消費し尽くさせることにより、この種の攻撃でサーバを
クラッシュさせることも可能です。サーバの ICMP 応答生成が速過ぎて、
ICMP 応答を送信し尽くすことができない場合、とくにひどいことになります。
.Bx Free
カーネルには、この種の攻撃の効果を抑制する ICMP_BANDLIM と
呼ばれる新しいコンパイルオプションがあります。
3つめの主要なクラスに属す踏み台攻撃は、udp echo サービスのように
ある種の内部 inetd サービスに関連するものです。攻撃者は単に
ソースアドレスがサーバ A の echo ポートであり、ディスティネーション
アドレスがサーバ B の echo ポートであるかのように UDP パケットを
偽造します。ここでサーバ A, B はともに自分の LAN に接続されています。
この 2 つのサーバは、この一つのパケットを両者の間で互いに相手に対して
打ち返しあいます。このようにしていくつかのパケットを注入することで、
攻撃者は両方のサーバと LAN を過負荷状態にすることができます。
同様の問題が内部 chargen ポートにも存在します。有能なシステム管理者は
この手の inetd 内部テストサービスのすべてを無効にしておくものです。
.Pp
Spoofed packet attacks may also be used to overload the kernel route cache.
Refer to the net.inet.ip.rtexpire, rtminexpire, and rtmaxcache sysctl
parameters. A spoofed packet attack that uses a random source IP will cause
the kernel to generate a temporary cached route in the route table, viewable
with 'netstat -rna | fgrep W3'. These routes typically timeout in 1600
seconds or so. If the kernel detects that the cached route table has gotten
too big it will dynamically reduce the rtexpire but will never decrease it to
less then rtminexpire. There are two problems: (1) The kernel does not react
quickly enough when a lightly loaded server is suddenly attacked, and (2) The
rtminexpire is not low enough for the kernel to survive a sustained attack.
If your servers are connected to the internet via a T3 or better it may be
prudent to manually override both rtexpire and rtminexpire via sysctl(8).
Never set either parameter to zero (unless you want to crash the machine :-)).
Setting both parameters to 2 seconds should be sufficient to protect the route
table from attack.
偽造パケット攻撃は、カーネルの経路情報キャッシュに過負荷を生じさせるために
用いられることもあります。net.inet.ip.rtexpire, rtminexpire, rtmaxcache
の sysctl パラメータを参照して下さい。でたらめなソース IP を用いた
この偽造パケット攻撃により、カーネルは、一時的なキャッシュ経路を
経路情報テーブルに生成します。これは
.Sq netstat -rna \&| fgrep W3
で見ることができます。これらの経路は、普通は 1600 秒程度でタイムアウトに
なります。カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを
検知すると、カーネルは動的に rtexpire を減らしますが、rtminexpire より
小さくなるようには決して減らしません。ここに問題が 2 つあります。
(1) 負荷の軽いサーバが突然攻撃された場合、カーネルが十分素早く反応
しないこと。(2) カーネルが攻撃に耐え生き延びられるほど十分
rtminexpire が低くなっていないこと。自分のサーバが T3 もしくはそれより
良質の回線でインターネットに接続されている場合、
.Xr sysctl 8
を用いて rtexpire と rtminexpire とを手動で上書きしておくことが思慮深いこと
といえます。
.Pq 自分のマシンをクラッシュさせたくない限りは:-
どちらかを 0 に
するようなことは決してしないで下さい。両パラメータを 2 秒に設定すれば、
攻撃から経路情報テーブルを守るには十分でしょう。
.Sh SEE ALSO
.Sh 関連項目
.Pp
.Xr accton 1 ,
.Xr chflags 1 ,
@ -440,8 +623,12 @@ table from attack.
.Xr syslogd 1 ,
.Xr xdm 1 ,
.Xr sysctl 8
.Sh HISTORY
The
.Sh 歴史
.Nm
manual page was originally written by Matthew Dillon and first appeared
in FreeBSD-3.0.1, December 1998.
マニュアルページは、もともと
.An Matthew Dillon
によって書かれました。
最初に現れたのは、
.Bx Free -3.0.1
で 1998 年 12 月のことです。
.\" translated by Norihiro Kumagai, 98-12-29

61
ja_JP.eucJP/man/man8/pam.8
View file

@ -1,7 +1,7 @@
.\" Hey Emacs! This file is -*- nroff -*- source.
.\" %Id: pam.8,v 1.2 1997/02/15 18:37:27 morgan Exp %
.\" Copyright (c) Andrew G. Morgan 1996-7 <morgan@linux.kernel.org>
.\" jpman %Id: pam.8,v 1.2 1999/02/10 12:44:48 horikawa Chk %
.\" jpman %Id: pam.8,v 1.3 1999/02/11 09:24:24 kuma Stab %
.TH PAM 8 "1997 Feb 9" "PAM 0.56" "PAM Manual"
.SH 名称
@ -23,16 +23,18 @@ PAM \-
.BR PAM
は、システム上でアプリケーション (サービス) の認証作業を行う
ライブラリシステムです。
本ライブラリが提供する
本ライブラリは、
一般的な不変のインタフェース
(アプリケーションプログラミングインタフェース - API) は、
(アプリケーションプログラミングインタフェース - API) を提供します。
.RB ( login "(1) "
や
.BR su "(1)) "
のような特権許可プログラムの標準の認証作業の実行を遅らせます。
.BR su "(1) のような) "
特権許可プログラム
がこの API に従うことで、
標準の認証作業を遂行するようになります。
.sp
PAM アプローチの基本機能は、認証の種類を動的に設定可能とすることです。
PAM アプローチの基本的な特徴は、認証作業の性質を動的に設定可能とすることです。
言い換えると、個々のサービス提供アプリケーションがユーザを認証する方法を、
システム管理者は自由に選択できます。
この動的設定は、単一の
@ -71,20 +73,22 @@ PAM
.sp
簡単に言うと、これらのグループは、
制限されたサービスに対する典型的なユーザ要求の異なった側面の面倒をみています。
それぞれ、
ある制限されたサービスに対する典型的なユーザ要求が持つ、異なった側面の
面倒をみています。
.sp
.BR account " - "
アカウント証明型のサービスを提供します。
「ユーザのパスワードが無効になったか？」
「このユーザが要求するサービスにアクセスを許されているか？」
「ユーザのパスワードが期限切れになったか？」
「このユーザは、要求するサービスにアクセスを許されているか？」
といった事柄を扱います。
.br
.BR auth "entication - "
ユーザが名乗っている人物であることを確定します。
典型的には、ユーザが満すべき「挑戦 - 応答」の要求で実現されます。
例えば「あなたが名乗っているその人であるなら、
ユーザが名乗っている人物本人であることを確定します。
この確定は、通常は、ユーザが満すべき「挑戦 - 応答」の要求で実現されます。
例えば「あなたが名乗っているその人本人であるなら、
あなたのパスワードを入力してください。」が該当します。
全部の認証がこの型であるわけではなく、
(スマートカードや生物測定学デバイスなどを使用する)
@ -98,11 +102,11 @@ PAM
.br
.BR password " - "
このグループの責任は、認証機構を更新することです。
典型的には、このようなサービスは
このようなサービスは
.BR auth
グループのサービスと強力な結び付きがあります。
グループのサービスと強く結び付いているのが普通です。
認証機構によっては、自己の更新をこの機能に任せているものがあります。
標準の UN*X のパスワードベースのアクセスは、明かな例です。
標準の UN*X のパスワードベースのアクセスは、明らかな例です。
「代わりのパスワードを入力してください。」がこれに該当します。
.br
@ -110,8 +114,9 @@ PAM
このグループの仕事は、サービス提供の前後に実行されるべきことをカバーします。
このような作業には、認証記録の維持と、
ユーザのホームディレクトリのマウントが含まれます。
開始時と終了時にモジュールへのフックを提供することにより、
ユーザが利用可能なサービスに影響を与えますので、
開始時と終了時に
ユーザが利用可能なサービスに影響を与える
モジュールへのフックを提供するので、
.BR session
管理グループは重要です。
@ -128,17 +133,17 @@ PAM
.BR /etc/pam.d/
ディレクトリの内容であることもあります。
これらのファイルは、サービスが要求する認証作業を行う
これらのファイルは、このサービスが要求する認証作業を行う
.BR PAM
と、個々の
の一覧と、個々の
.BR PAM
が失敗したときの PAM-API の適切な動作をリストします。
が失敗したときの PAM-API の適切な動作の一覧をリストします。
.sp
.B /etc/pam.conf
設定ファイルの文法は次の通りです。
ファイルはルールのリストから構成されます。
個々のルールは典型的には単一行ですが、
個々のルールは普通は単一行ですが、
`\\<LF>' で行末をエスケープすることで複数行に渡ることが可能です。
コメントは、前に `#' マークを置き、行末まで続きます。
@ -171,12 +176,12 @@ PAM
.sp
.BR service
は、典型的には対応するアプリケーションの親しみのある名前です。
は、普通は、対応するアプリケーションの親しみのある名前です。
.BR login
や
.BR su
は良い例です。
.BR service " の名前 " other
.BR service " 名 " other
は
.I デフォルト
ルールを与えるために予約されています。
@ -187,8 +192,8 @@ PAM
.sp
.BR type
は、ルールが対応する管理グループです。
後続するモジュールがどの管理グループに関連付けられるべきかを
は、そのルールに対応する管理グループです。
後続するモジュールをどの管理グループに関連付けるべきかを
指定するために使用されます。
有効なエントリは
.BR account "; "
@ -206,14 +211,14 @@ PAM
.BR control
の値は次の通りです。
.BR requisite
- この PAM が失敗すると、認証処理は即時停止します;
- この PAM が失敗すると、認証処理は即ちに終了します;
.BR required
- この PAM が失敗すると、究極的には PAM-API は失敗を返しますが、
それはこの
.RB "(" service
および
.BR type
の) 積み重なっているモジュールの残りを起動した後です;
の) 積み重なっているモジュールの残りが呼び出されたあとです;
.BR sufficient
- この種のモジュールが成功すると、
モジュールの積み重ねの認証条件を満します
@ -261,7 +266,7 @@ PAM
.SH 準拠
DCE-RFC 86.0, October 1995.
.br
現在 DCE-RFC 委員会で考察されている追加機能があります。
現在 DCE-RFC 委員会で検討されている追加機能も含まれています。
.SH バグ
.sp 2

6
ja_JP.eucJP/man/man8/usbdevs.8
View file

@ -1,6 +1,6 @@
.\" %NetBSD: usbdevs.8,v 1.3 1998/07/23 13:57:51 augustss Exp %
.\" FreeBSD %Id: usbdevs.8,v 1.2 1998/12/14 09:40:15 n_hibma Exp %
.\" jpman %Id: usbdevs.8,v 1.4 1999/02/11 07:49:20 horikawa Stab %
.\" jpman %Id: usbdevs.8,v 1.5 1999/02/11 16:53:58 horikawa Stab %
.\" Copyright (c) 1998 The NetBSD Foundation, Inc.
.\" All rights reserved.
.\"
@ -47,8 +47,8 @@
.Op Fl v
.Sh 解説
.Nm
は、システムに接続されているすべての USB 機器を、
それぞれの機器に関する多少の情報と共に表示します。
は、システムに接続されているすべての USB 機器の一覧を、
それぞれの機器に関するいくらかの情報とともに表示します。
各行のインデントは root からの距離を示しています。
.Pp
オプションは次の通りです: