diff --git a/ja/man/man5/isdnd.rc.5 b/ja/man/man5/isdnd.rc.5
index b75ce8ea38..a506d95649 100644
--- a/ja/man/man5/isdnd.rc.5
+++ b/ja/man/man5/isdnd.rc.5
@@ -1,681 +1,682 @@
 .\"
 .\" Copyright (c) 1997, 1998 Hellmuth Michaelis. All rights reserved.
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
 .\" 1. Redistributions of source code must retain the above copyright
 .\"    notice, this list of conditions and the following disclaimer.
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
 .\"
 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" 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]
 .\"
 .\" WORD: exchange	交換局
 .\" WORD: subscribe	(AOCD サービス等を) 申し込んでいる
 .Dd October 27, 1998
 .Dt isdnd.rc 5
 .Sh 名称
 .Nm isdnd.rc
 .Nd isdn4bsd ISDN 接続管理デーモンの設定ファイル書式
 .Sh 解説
 (コマンドラインで別のものを指定しない限り) ファイル
 .Pa /etc/isdn/isdnd.rc
 は、
 .Xr isdnd 8
 ISDN 接続管理デーモンの実行時設定を格納します。
 本デーモンは、isdn4bsd パッケージの一部です。
 .Pp
 設定ファイルには、第 1 桁から始まるキーワードが複数含まれます。
 キーワードの後には、1 個以上の空白・タブ、単一の等号、1 個以上の空白・タブ、
-キーワード依存のパラメータ値が続きます。
+キーワード依存のパラメータ値と続きます。
 .Pp
 文字 '#' で開始する行はコメント行として扱われます。
 .Pp
 ブール値指定を要求するキーワードに対しては、真を
 .Em yes
 または
 .Em on
 で与え、偽を
 .Em no
 または
 .Em off
 で与えます。
 .Pp
 設定ファイルには、単一の
 .Em システム
 セクションと 1 個以上の
 .Em エントリ
 セクションが含まれます。
 .Em システム
 セクションでは、デーモンの操作に関するパラメータや
 単一のリモート接続に関連付けられないパラメータを設定可能です。
 .Em エントリ
 セクションでは、
 単一のリモート接続に直接関連付けられたパラメータを設定可能です。
 .Pp
 次のキーワードを
 .Nm isdnd
 は理解します:
 .Pp
 .Bl -tag -width system -compact
 
 .It Li system
 本キーワードにより、システム設定セクションが開始します。
 パラメータを伴ってはなりませんし、1 度のみ使用可能です。
 本キーワードは必須です。
 次のキーワードは、システム設定セクション内で有効です:
 .Bl -tag -width useacctfile -compact
 
 .It Li acctall
 本パラメータを
 .Em on
 に設定すると、
 ローカルサイトが課金されてない場合や、
 課金情報が利用不能だったり課金情報を申し込んでいない場合でも、
 アカウンティング情報が書き込まれます。(省略可能)
 
 .It Li acctfile
 キーワード
 .Em useacctfile
 (後述) が
 .Em on
 に設定されたときに使用されるアカウンティングファイルの名前を指定します。
 本キーワードを指定しないと、システムデフォルトが使用されます。(省略可能)
 
 .It Li aliasing
 本パラメータが
 .Em on
 に設定されると、電話番号から名前へのエイリアス処理が有効にされます (後述の
 .Em aliasfile
 キーワードも参照)。デフォルトは off です。(省略可能)
 
 .It Li aliasfile
 .Em aliasing
 キーワードによりエイリアス処理が有効にされたときに
 .Xr isdntel 1
 ユーティリティと共有される、
 電話番号から名前へのエイリアスデータベースファイルの名前を指定します。
 (省略可能)
 
 .It Li isdntime
 本パラメータが
 .Em on
 に設定されると、(提供されるならば) 交換局から得られる日付/時刻情報を
 ログファイルに書き込みます。デフォルトは off です。(省略可能)
 
 .It Li monitor-allowed
 本パラメータが
 .Em on 
 または
 .Em yes
 に設定されると、
 ローカルマシンまたはリモートマシンを介した監視が有効になります。
 本パラメータは省略可能であり、デフォルトで
 .Em off
 に設定されます。
 
 .It Li monitor-port
 リモート監視用の TCP ポート番号を設定します。
 本整数パラメータは省略可能であり、デフォルトでポート 451 に設定されます。
 
 .It Li monitor
 本キーワードは、ローカルソケット名または、
 リモート監視用にホストまたはネットワークを指定します。
 .Em monitor 
 の指定は次のいずれかです:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar ローカル (UNIX ドメイン) ソケット名
 文字 "/" で開始する必要があります。例: /var/run/isdn-monitor
 .It Ar ドット付き 4 つ組のホスト指定
 例: 192.168.1.2
 .It Ar ドット付き 4 つ組のネットワークアドレスとネットマスク
 例: 192.168.1.0/24
 .It Ar 解決可能なホスト名
 例: localhost
 .It Ar 解決可能なネットワーク名とネットマスク
 例: up-vision-net/24
 .El
 
 .It Li monitor-access
 本キーワードは、以前使用した
 .Em monitor
 キーワードのアクセス権限を指定します。
 サポートされているアクセス権限は次の通りです:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar fullcmd
 .It Ar restrictedcmd
 .It Ar channelstate
 .It Ar logevents
 .It Ar callin
 .It Ar callout
 .El
 
 .It Li ratesfile
 料金ファイルの名前を指定します。
 本キーワードが省略された場合、システムデフォルトが使用されます。(省略可能)
 
 .It Li regexpr
 本キーワードは、正規表現を指定するために使用されます。
-1 度より多く指定することが可能であり、
-コンパイル時に依存する値まで指定可能です
-(現在、ソースにおける MAX_RE の定義により、5 に設定されます)。
+1 度以上、コンパイル時依存の回数
+(現在、ソースにおける MAX_RE の定義では 5 回)
+まで指定することが可能です。
 .Pp
 指定した全正規表現は実行時にログ文字列と比較され、
 マッチした場合には、ログテキストをパラメータとしてプログラムが実行されます
 (後述のキーワード
 .Em regprog
 も参照)。
 .Pp
 正規表現の指定方法については、
 .Xr re_format 7
 と
 .Xr regex 3
 を参照してください。
 .Em 拡張
 正規表現の書式がサポートされています。
 .Pp
 ヒント: 設定ファイルのパーザが不適切に解釈することを避けるために、
 式を適切にクォートする必要があるかもしれません。
 (省略可能)
 
 .It Li regprog
 本キーワードは、対応する正規表現がログ文字列にマッチした場合に実行される、
 プログラムの名前を指定するために使用されます。
 .Nm isdnd
 は、パス
 .Pa /etc/isdn
 以下でプログラムを見付けられるものと期待します。
 このパスは、本キーワードのパラメータとして指定された文字列の前に付けられます。
 (省略可能)
 
 .It Li rtprio
 .Nm isdnd
-が実行されるリアルタイム優先度を、整数値範囲 0 〜 31 で指定します。
+が実行されるリアルタイム優先度を、0 〜 31 の範囲の整数値で指定します。
 0 は最高の優先度です。
 本キーワードは省略可能です。
 指定しない場合、
 .Nm isdnd
 の処理優先度はまったく修正されません。(
 .Xr rtprio 1 
 も参照)。
 本キーワードは、
 .Nm
 を -DUSE_RTPRIO 付きでコンパイルした場合にのみ利用可能です。
 
 .It Li useacctfile
 本パラメータが
 .Em on
 に設定された場合、(利用可能な場合) 課金情報とアカウンティング情報が
 アカウンティングファイルに書き込まれます。(省略可能)
 
 .El
 
 .It Li entry
 本キーワードにより、単一の設定エントリが開始します。
 パラメータを伴ってはなりません。
 本キーワードは、少なくとも 1 度は使用する必要があります。
 次のキーワードは、エントリセクション内で有効です:
 .Bl -tag -width unitlengthsrc -compact
 
 .It Li answerprog
-本キーワードは、内向き電話接続が設定エントリにおいて
+本キーワードは、着信電話接続が設定エントリにおいて
 .Em answer
 を指定した場合に実行される、プログラムの名前を指定するために使用されます。
 デフォルト名は
 .Em answer
 です。
 .Nm isdnd
 は、パス
 .Pa /etc/isdn
 以下でプログラムを見付けられるものと期待します。
 このパスは、本キーワードのパラメータとして指定された文字列の前に付けられます。
 (省略可能)
 
 .It Li alert
-呼び出しを受け付ける前に待つ秒数を指定するために使用します。
-本キーワードは、内向き電話呼び出し (dialin-reaction = answer)
+呼 (call) を受け付ける前に待つ秒数を指定するために使用します。
+本キーワードは、電話着呼 (dialin-reaction = answer)
 のためにのみ指定可能です。
-応答マシンが実行を開始する前に、
-電話の内向き呼び出しを受け付ける機会を持つために、使用します。
+留守番マシンが実行を開始する前に、
+電話の着呼 (incoming call) を受け付ける機会を持つために使用します。
 本パラメータの最小値は 5 秒であり、パラメータの最大値は 180 秒です。
 (省略可能)
 
 .It Li b1protocol
 本接続に使用される B チャネルのレイヤ 1 プロトコルです。
 本キーワードは必須です。
 現在設定可能な値は次の通りです:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar hdlc
 HDLC フレーミング。
 .It Ar raw
 フレーミングを行わない (電話通信のために使用)。
 .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
 本キーワードは、どのタイプのダイヤルアウトモードが使用されるかを設定します。
 本キーワードは必須です。
 現在サポートされているパラメータは次の通りです:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar normal
-通常動作。呼び出しを受け付けると思われるリモートサイトを呼び出します。
+通常動作。呼を受け付けると思われるリモートサイトを呼び出します。
 .It Ar calledback
 コールバック動作。
-呼び出しを拒否してから当方にコールバックするリモートサイトを呼び出します。
+呼を拒否してから当方にコールバックするリモートサイトを呼び出します。
 .El
 
 .It Li dialrandincr
 ダイヤル時または再ダイヤル時、本パラメータが
 .Em on
 に設定されていると、
 ダイヤル再試行時間に乱数 (現在 0 〜 3 秒) が加えられます。
 2 つのサイトが同期してダイヤルしてしまい、
 他方もダイヤルしているために双方がダイヤルする度にビジーを検出するという機会を
 最小化します。
 
 .It Li dialretries
-ダイヤルを諦める前に再試行する回数です。(省略可能)
+ダイヤルをあきらめる前に再試行する回数です。(省略可能)
 
 .It Li direction
-本キーワードは、内外向き・内向きのみ・外向きのみのいずれの接続が可能であるかを
+本キーワードは、発信着信・発信のみ・着信のみのいずれの接続が可能であるかを
 設定するために使用します。
 本キーワードは省略可能であり、デフォルトは
 .Em inout
 です。
 .Pp
 現在サポートされているパラメータは次の通りです:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar inout
 通常動作。接続の確立は、リモートからでもローカルからでも可能です。
 .It Ar in
-内向き接続のみ可能です。
+着信接続のみ可能です。
 .It Ar out
-外向き接続のみ可能です。
+発信接続のみ可能です。
 .El
 
 .It Li downtries
 失敗する試行回数を指定するために使用します。
-失敗する試行 (=再試行サイクルです!) をこの回数だけ行った後、
+試行 (=再試行サイクルです!) がこの回数だけ失敗すると、
 インタフェースを (
 .Em downtime
 秒だけ) 無効にします。
 (詳細はキーワード
 .Em usedown
 を参照)。本キーワードは省略可能です。
 
 .It Li downtime
 .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) を指定すると本機能を無効化します。これがデフォルト値です。
 本機能は
 .Xr i4bipr 4
 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
 ローカルサイトからダイヤルアウトする場合に使用される、ローカルの電話番号。
 リモートサイトに対してダイヤルアウトするとき、
 ここで指定した番号が
 .Em "発番号情報要素 (Calling Party Number Information Element)"
 に埋め込まれます。
 .Pp
-本キーワードは、ipr ユーザランドインタフェース用のために必須です。
+本キーワードは、ipr ユーザランドインタフェースのために必須です。
 .\" 原文の .em (Execute Macro) は、引数無しの場合効果が無いので削除
 .\" horikawa@jp.freebsd.org 1999/01/19
 
 .It Li local-phone-incoming
-内向き呼び出しの宛先を確認するために使用する、ローカルの電話番号です。
+着呼の宛先を確認するために使用する、ローカルの電話番号です。
 リモートサイトがダイヤルインするとき、
 リモートサイトの希望接続先がローカルサイトであることを確認するために、
 本番号を使用します。
 この値は、電話交換局から得られる
 .Em "着番号情報要素 (Called Party Number Information Element)"
 と比較されます。
 .Pp
 本キーワードは ipr インタフェースのために必須です。
 
 .It Li name
-本設定エントリにシンボルによる名前を定義します。
+その設定エントリにシンボルによる名前を定義します。
 全画面表示においてこの名前を使用して
-リモートサイトへのリンクを識別し易くすることと、
+リモートサイトへのリンクを識別しやすくすることと、
 アカウンティングに使用することを目的としています。(必須)
 
 .It Li ratetype
 料金ファイル中の、使用する料金エントリ。(省略可能)
 .br
 例えば、
 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
 
 .It Li remote-phone-dialout
 ローカルサイトからダイヤルアウトする場合に使用される、リモートの電話番号。
 リモートサイトに対してダイヤルアウトするとき、
 ここで指定した番号が
 .Em "着番号情報要素 (Called Party Number Information Element)"
 に埋め込まれます。
 .Pp
-本キーワードは、ipr インタフェース用のために必須です。
+本キーワードは、ipr インタフェースのために必須です。
 .\" 原文の .em (Execute Macro) は、引数無しの場合効果が無いので削除
 .\" horikawa@jp.freebsd.org 1999/01/19
-どれかひとつが成功するまでいくつかの番号に対して試行させるために、
-複数回指定可能です。
+複数回指定して、
+どれかひとつが成功するまでいくつかの番号に対して試行させることもできます。
 
 .It Li remote-phone-incoming
-内向き呼び出しを確認するために使用する、リモートの電話番号です。
+着呼を確認するために使用する、リモートの電話番号です。
 リモートサイトがダイヤルインするとき、
 ローカルシステムに対して接続する権限がある
 正しいリモートサイトであることを確認するために、
 本番号を使用します。
 この値は、電話交換局から得られる
 .Em "発番号情報要素 (Calling Party Number Information Element)"
 と比較されます。
 .Pp
 本キーワードは ipr インタフェースのために必須です。
 .Pp
-本キーワードを、ワイルドカードパラメータ '*' として、
+本キーワードにワイルドカードパラメータ '*' を渡して、
 誰もがダイヤルイン可能とできます。
 
 .It Li unitlength
 秒数による課金単位の長さ。
-アイドルタイムとともに使用して、接続をいつハングアップするのかを決定します。
+アイドル時間とともに使用して、いつ接続を切るのかを決定します。
 (省略可能)
 
 .It Li unitlengthsrc
 本キーワードは、ショートホールドモードにおいて
 .Xr isdnd 8
 がどこから unitlength を取得するかを指定します。
 現在設定可能な値は次の通りです:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar none
 unitlength は、どこにも指定されません。
 .It Ar cmdl
 コマンドラインで指定される unitlength を使用します。
 .It Ar conf
 設定ファイルでキーワード
 .Em unitlength
 で指定される 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
 
 .It Li usrdevicename
 ISDN B チャネルデータをユーザランドにインタフェースするために使用する、
 ユーザランドインタフェースを指定します。
 本キーワードは必須です。
 本キーワードは次のパラメータを受け付けます:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar ipr
 本パラメータは raw HDLC IP over ISDN インタフェースを設定します。
 .It Ar isp
 本パラメータは shyncronous PPP over ISDN インタフェースを設定します。
 .It Ar rbch
 本パラメータは Raw B CHannel アクセスインタフェースを設定します。
 .It Ar tel
 ISDN 電話通信。
 .El
 
 .It Li usrdeviceunit
 usrdevicename が指定するデバイスの、ユニット番号を指定します。
 .\" 原文の .em (Execute Macro) は、引数無しの場合効果が無いので削除
 .\" horikawa@jp.freebsd.org 1999/01/19
 .\" 文法もちょっとヘンですね。
 .\" Specifies the unit number for the with the
 .\" .em
 .\" usrdevicename
 .\" specified device.
 
 .It Li usedown
 エントリセクションにおいて、キーワード
 .Em downtries
 と
 .Em downtime
-を使用可能とするために使用します。
+を有効にするために使用します。
 (回線ビジーの場合等) 遷移に失敗する場合に、
-過度のダイヤルアクティビティを避けるために、
+過度のダイヤル動作を避けるために、
 .Nm isdnd
 が IP インタフェースの有効・無効を動的に切り替えるために使用します。
 本パラメータは省略可能であり、デフォルトで
 .Em off
 に設定されます。
 
 .It Li connectprog
 接続が確立してアドレス交渉が完了した後 (すなわち接続を使用可能となった後)、
 毎回実行するプログラムを指定します。
 .Nm isdnd
 は、パス
 .Pa /etc/isdn
 以下でプログラムを見付けられるものと期待します。
 このパスは、本キーワードのパラメータとして指定された文字列の前に付けられます。
 (省略可能)
 
 .It Li disconnectprog
 接続がシャットダウンされた後、毎回実行するプログラムを指定します。
 .Nm isdnd
 は、パス
 .Pa /etc/isdn
 以下でプログラムを見付けられるものと期待します。
 このパスは、本キーワードのパラメータとして指定された文字列の前に付けられます。
 (省略可能)
 
 .El
 .El
 
 .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 (ゼロ) 以上であることが必要です
 。
 
 .Bd -literal
 
 |<unchecked window>|<checkwindow>|<safetywindow>|
 |                  |             |              |
 +------------------+-------------+--------------+
 |                  |             |              |
 |                  |<-idle-time->|<earlyhangup->|
 |<--------------unitlength--------------------->|
 
 .Ed
 
 チェック対象外ウィンドウ (uncheked window) は、
 (unitlength - (idle-time + earlyhangup)) の長さであり、
 この間アイドルチェックはされません。
 チェック対象外ウィンドウが終ると、idle-time の期間、
 回線にトラフィックが無いかチェックされます。
 チェックウィンドウ (check-window) の期間にトラフィックが検出された場合、
 次の単位 (unit) の先頭から同じ手続きが再度開始されます。
-チェックウィンドウ (check-window) の期間トラフィックが検出されない場合、
+チェックウィンドウの期間トラフィックが検出されない場合、
 チェックウィンドウ終了時に回線が閉じられます、
 .Pp
 注釈:
 .Em unitlength
 は
 .Em idletime-outgoing
 と
 .Em earlyhangup
 の合計よりも大きいことが必要 (!) です!
 
 .El
 .El
 
 .Pp
 
 .Sh 関連ファイル
 .Bl -tag -width /etc/isdn/isdnd.rc -compact
 .It Pa /etc/isdn/isdnd.rc
 .Nm isdnd
 ISDN デーモンのデフォルトの設定ファイル。
 
 .Sh 関連項目
 .Xr isdnd 8
 .Xr isdnmonitor 8
 .Xr regex 3
 .Xr re_format 7
 
 .Sh 作者
 .Xr isdnd 8
 デーモンと本マニュアルページは Hellmuth Michaelis が書きました。
 彼の連絡先は、hm@kts.org です。
diff --git a/ja/man/man7/security.7 b/ja/man/man7/security.7
index 32632118d6..534e92d12a 100644
--- a/ja/man/man7/security.7
+++ b/ja/man/man7/security.7
@@ -1,447 +1,634 @@
 .\" Copyright (c) 1998, Matthew Dillon.  Terms and conditions are those of
 .\" the BSD Copyright as specified in the file "/usr/src/COPYRIGHT" in
 .\" 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.
-.Pp
-Security concerns can be split up into several categories:
+システムは昔からマルチユーザに対応しています。セキュリティの仕組みを
+組み込んで維持することで、ユーザを
+.Sq 正直に
+し続ける仕事は、システム管理者の最も大きな責務の一つでしょう。マシンは、
+管理者が設定しただけのセキュリティしか示しません。セキュリティに関する
+問題は、むしろ、便利さを求める人間との競合問題です。一般に、
+.Ux
+システムは莫大な数のプロセスを同時に実行させることも、また、その多くを
+サーバとして動作させることもできます。これは、外部の何者かが
+接続してきて、サーバプロセスと会話することができるということを
+意味します。昨日までのミニコンピュータとメインフレームは、今日では
+デスクトップコンピュータとなり、かつ、それらはネットワークで結ばれて
+インターネットと接続されるようになりました。これにより、セキュリティは
+昔と比べてはるかに大きな問題となっています。
+.Pp
+セキュリティに関する問題は、いくつかのカテゴリに分類することができます。
 .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.
-.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.
-.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.
-.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.
-.Pp
-Security remedies are always implemented in a multi-layered 'onion peel' 
-approach and can be categorized as follows:
+サービス不能攻撃とは、マシンから必要な資源を奪う行為です。
+サービス不能攻撃は、普通は、そのマシンで実行されるサーバや
+ネットワークスタックを圧倒して、マシンを使えなくしたりクラッシュさせようと
+するような力任せの仕組みです。サービス不能攻撃のいくつかは、
+ネットワークスタックのバグを利用して、パケット一つでマシンを
+クラッシュさせようとします。後者は、
+カーネルにバグ修正を施すことによってのみ修正することができます。
+サーバプロセスに対する攻撃は、サーバのオプションを適切に指定して、
+逆境状況のシステムにおいて、サーバプロセスが引き起こす負荷に限界を設けることで
+修正することができます。これらに比べると、ネットワークへの力任せの攻撃への
+対応はずっと難しくなります。たとえば、偽造パケットによる攻撃
+.Pq spoof-packet attack
+は、インターネットからシステムを切り離す以外の方法では、抑止することは
+ほとんど不可能です。
+.Pp
+ユーザアカウントを危険に晒すことは、サービス不能攻撃よりは多少はありふれた
+ものです。このご時勢でも、システム管理者の多くは、自分たちのマシンで
+標準の telnetd, rlogind, rshd, ftpd サーバを実行させています。これらの
+サーバは、デフォルトでは、暗号化されたコネクション上で動作していません。
+その結果、抱えているユーザ数が標準的な大きさならば、リモート
+.Pq そのシステムにログインするのに最も普通で便利な場所
+からログインしているユーザのうち一人以上は、パスワードを覗き見られて
+しまうでしょう。
+システム管理者が注意深いならば、たとえログインが成功していたとしても、
+リモートアクセスログをときどき解析して、疑わしいソースアドレスを探すものです。
+.Pp
+ひとたび攻撃者がユーザアカウントへのアクセス権を入手すると、攻撃者が
+root の権限を破る可能性があることを仮定するべきです。しかし、
+セキュリティを十分保ち、手入れの行き届いたシステムにおいては、
+あるユーザアカウントへのアクセスが可能となっても、攻撃者に必ずしも
+root へのアクセス権を与えるとは限らないのが現実です。この違いは重要です。
+というのは、root へのアクセス権がなければ、一般的に、攻撃者は自分の
+侵入の痕跡を隠蔽することができませんし、そのユーザのファイルを消して
+マシンをクラッシュさせることができるのがせいぜいで、他のユーザの
+ファイルには手出しできません。
+.Pp
+システム管理者は、あるマシン上で root の権限を破る方法がいくつかあることを
+心しておかねばなりません。攻撃者が root のパスワードを知ってしまうかも
+しれません。攻撃者が root の権限で実行されるサーバのバグを見つけ、
+ネットワークからそのサーバへ接続して root の権限を破ることができるかも
+しれません。ひとたびユーザアカウントを破ると、ユーザアカウントから
+root の権限を破ることが可能であるバグを持つ suid-root プログラムの
+存在を、攻撃者は知っているかもしれません。
+.Pp
+セキュリティを改善する方法は、常に、
+.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
-.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.
-.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.
-.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.
-.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
-.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!
-.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.
-.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.
-.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
-.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
-.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.
-.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
-.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.
-.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
-.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.
-.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.
-.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.
-.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.
-.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.
-.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
-.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
-.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.  
+.Sh root アカウントとスタッフアカウントの安全性を高める
+.Pp
+root のアカウントの安全性を確保しないうちからスタッフのアカウントの安全性を
+うんぬんしてもしかたがありません。ほとんどのシステムでは、root アカウントに
+割り当てたパスワードがひとつあります。まず最初にすべきことは、
+このパスワードは
+.Sq いつでも
+危険に晒されていると仮定することです。root アカウントの安全性を確保する
+ためには、ネットワーク越しに、あるいはどれか一般ユーザのアカウントから、
+root のパスワードを使って root アカウントにログインすることが決して
+できないことを確実にすることです。正しいパスワードが与えられようが
+与えられまいが、telnetd, rlogind, その他ログイン処理を行なうサーバ
+すべてで root でのログインを拒絶するように設定していないとするなら、
+今すぐそういうふうに設定して下さい。直接 root でログインできるのは、
+システムコンソールからだけにして下さい。ここで役に立つのが
+.Sq /etc/ttys
+ファイルです。ほとんどのシステムでは、デフォルトで安全ですが、
+優れたシステム管理者は、設定がそうなっているか常にチェックを怠らない
+ものです。
+.Pp
+システム管理者として、自分は root になれるようにしておかねばならないの
+はもちろんですから、穴をいくつか空けておきます。しかし、それらの穴を
+動作させるには、さらに追加のパスワード認証が必要であるようにして
+おきます。root でアクセス可能とする方法の一つとして、
+適切なスタッフアカウントを
+.Pq /etc/group の
+wheel グループに加えることがあります。
+wheel グループに置かれたスタッフメンバには、
+.Sq su
+を使って root になることが許されます。スタッフメンバに、
+パスワードファイルのエントリでそのまま wheel のアクセス権を
+与えてはいけません。スタッフは、
+.Sq staff
+かその類のグループに置き、その中で本当に root になる必要がある人
+だけを wheel グループに加えるようにします。残念ながら、wheel の
+仕組みだけだと、侵入者がパスワードファイルを手に入れると、攻撃者が
+破る必要があるのは root のパスワードか、wheel グループにたまたま属す
+staff アカウントの一つのパスワードだけです。wheel の仕組みは有益
+ですが、wheel グループがまったく存在しない状況と比べてそれほど
+安全なわけではありません。
+.Pp
+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
+より間接的なセキュリティの仕組みは、より制限の強いサーバから制限の弱い
+サーバへログインすることを前提としています。例えば、主マシンで、
+すべての種類のサーバを実行させている場合、ワークステーションではそれらの
+サーバを実行させてはなりません。ワークステーションの安全性を比較的
+高めておくためには、実行するサーバの数を、果てはサーバなしまで、
+できるだけ減らしておくべきです。また、パスワード防護された
+スクリーンセーバを走らせておくべきです。
+ワークステーションへの物理的アクセスが与えられたとすると、攻撃者は
+管理者が設定したいかなる種類のセキュリティをもうち破ることができるのは
+もちろんのことです。これは、管理者として考えておかねばならない決定的な
+問題ですが、システム破りの大多数は、ネットワーク経由でリモートから、
+ワークステーションやサーバへの物理的アクセス手段を持たない人々によって
+行なわれるという事実も、また、念頭に置いておく必要があります。
+.Pp
+kerberos のような方法を使うことで、スタッフアカウントのパスワードの変更
+もしくは停止を一箇所で行なうことと、スタッフメンバがアカウントを持つ
+すべてのマシンに即時にその効果を及ぼすことが可能となります。スタッフメンバの
+アカウントが危険に晒されたときに、すべてのマシンでその人のパスワードを
+即座に変更する機能を甘く見てはいけません。パスワードが分散されていると、
+N 台のマシンでパスワードを変更することは、てんやわんやの事態を招く可能性が
+あります。kerberos による再パスワード制限
+.Pq re-passwording restriction
+を課することもできます。これを使うことにより可能となることは、
+ある kerberos チケットをしばらくしてからタイムアウトにすることだけでなく、
+kerberos システムがユーザに一定期間
+.Pq 例えば、1 ヶ月に 1 回
+の後に新しいパスワードを選ぶことを要求することもできます。
+.Sh root の安全性を高める - root 権限のサーバと suid/sgid バイナリ
+.Pp
+用心深いシステム管理者は、自分に必要なサーバプロセスだけを過不足なく
+実行させるものです。第三者製のサーバはしばしばバグの温床であることに
+注意して下さい。例えば、古いバージョンの 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
+.Bx Free
+では、今では ntalkd, comsat, finger は砂場で実行させることが
+デフォルトになっています。次に砂場で実行させるべきプログラムの候補として、
+.Xr named 8
+があります。デフォルトの rc.conf ファイルには、named を砂場で実行する
+ために必要な引数がコメントアウトされた形式で含められています。新しい
+システムをインストールしているか、それとも既存のシステムを
+アップグレードして使っているかに依存しますが、砂場として使用する
+特別のユーザアカウントがインストールされていないかもしれません。用心深い
+システム管理者は研究を怠らず、可能なところではつねにサーバに砂場を仕込む
+ものです。
+.Pp
+通常、砂場で実行しないサーバが他にいくつかあります。sendmail, popper,
+imapd, ftpd などです。これらのうちいくつかには代わりがありますが、
+代わりのものをインストールするには、それだけ多くの仕事が必要になるので、
+結局これらを喜んで入れてしまいます
+.Pq 簡単度がまたも勝利を収めるわけです
+。
+これらのサーバは、root 権限で実行せねばならず、これら経由で生じる侵入の
+検出のためには、他の仕組みに依存せねばならないかもしれません。
+.Pp
+システムの 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
+ユーザアカウントは、普通、安全性を高めることが最も困難です。
+スタッフに対して、アテナイのドラコのような厳格なアクセス制限を課し、
+スタッフのパスワードを\ * で外すことができるとはいえ、管理者が持ちうる
+一般ユーザすべてのアカウントに対して同じことはできないかも知れません。
+十分な管理を保つならば、管理者は勝利し、ユーザの
+アカウントを適切な状態で安全を確保できるかもしれません。それが
+保てないならば、一般ユーザのアカウントをモニタしていっそう気を配るように
+するしかありません。一般ユーザアカウントでの ssh や kerberos の利用は、
+いろいろ問題をはらんでいます。それでも、暗号化パスワードと比較すると、
+はるかに良い解です。
+.Sh パスワードファイルの安全性を高める
+.Pp
+できるだけ多くのパスワードを\ * で外し、それらのアカウントのアクセスには
+ssh や kerberos を使うようにすることが、唯一の確実な方法です。たとえ暗号化
+パスワードファイル 
+.Pq /etc/spwd.db
+が root でのみ読み出し可能だとしても、
+たとえ root の書き込み権限が得られないにしても、侵入者がそのファイルの
+読み出しアクセス権限を得ることは可能かも知れません。
+.Pp
+セキュリティスクリプトは常にパスワードファイルの変更をチェックし、報告
+するようにすべきです (後述の「ファイルの完全性のチェック」を参照して下さい)。
+.Sh カーネルのコア、raw デバイス、ファイルシステムの安全性を高める
+.Pp
+root の権限を破ると、攻撃者はほとんど何でもできますが、
+もっと簡便なこともいくつかあります。例えば、最近のカーネルのほとんどでは、
+組み込みのパケット覗き見デバイス
+.Pq packet sniffing device
+ドライバを備えています。
+.Bx Free
+では
+.Sq bpf
+デバイスと呼ばれています。侵入者は普通、危険に晒された
+マシンでパケット覗き見プログラムを実行させようと試みます。侵入者に
+わざわざそういう機能を提供する必要はないので、ほとんどのシステムで bpf
+デバイスを組み込むべきではありません。不幸なことに、ローダブルカーネル
+モジュール 
+.Pq Loadable Kernel Module:LKM
+インタフェースと呼ばれる
+カーネル機能があります。やる気まんまんの侵入者は、LKM を使って
+自分独自の bpf もしくはその他覗き見デバイスを動作中のカーネルに
+インストールすることが可能です。
+モジュールローダを使う必要がないのであれば、カーネル設定で
+NO_LKM オプションを設定してこの機能を無効にして下さい。
+.Pp
+bpf デバイスを外し、モジュールローダを無効にしても、/dev/mem と /dev/kmem
+という悩みの種がまだ残っています。この問題に関しては、侵入者は raw
+デバイスに書き込むこともできます。この問題を避けるため、システム管理者は
+カーネルをより高い安全レベル
+.Pq securelevel
+、少なくとも安全レベル 1 で実行させる必要があります。
+sysctl を使って kern.securelevel 変数に安全レベルを設定することが
+できます。ひとたび安全レベルに 1 を設定すると、
+raw デバイスに対する書き込みアクセスは拒否され、例えば
+.Sq schg
+のような
+特別な chflags フラグが効果を発揮します。これに加えて、
+起動において重要なバイナリ・ディレクトリ・スクリプトファイルなど、
+安全レベルが設定されるまでの間に実行されるものすべてに対しても
+.Sq schg
+フラグを確実に on にしておく必要があります。この設定をやり過ぎても
+構いませんが、より高い安全レベルで動作している場合、システムの
+アップグレードがはるかに困難になります。システムをより高い安全レベルで
+実行させるようにするが、お天道さまの下にあるすべてのシステムファイルと
+ディレクトリに schg フラグを設定しないという妥協をする方法もあります。
+.Sh ファイルの完全性のチェック: バイナリ、設定ファイルなど
+.Pp
+ことここに至るとシステム管理者にできることは、
+便利度がその醜い頭を上げない程度に、
+コアシステムの設定 / 制御ファイルを防御することだけです。
+セキュリティのタマネギの最後の層はおそらく最も重要なもの、すなわち探知です。
+.Pp
+システムファイルの完全性をチェックする唯一の正しい方法は、別の、より安全な
+システム経由で行なう方法だけです。
+.Sq 安全
+なシステムを準備することは比較的
+容易です。単に、サービスを一切実行しないようにするだけです。安全なシステム
+を用いて、ssh 経由で他のシステムの root 空間にアクセスします。これは
+セキュリティの末端のように見えるかもしれません。しかし、管理者には信頼を
+どこかに置く必要があります。いきあたりばったりでサーバプロセスを
+実行するような馬鹿げたことをしない限りは、安全度の高いマシンを構築する
+ことは本当に可能です。ここで
+.Sq 安全
+という場合、物理アクセスに対する
+セキュリティをも含めて仮定していることはもちろんです。安全なマシンで、
+他のすべてのマシンに root のアクセス権限を持つものが得られると、
+「安全なマシンの上で」システムの他のマシンをチェックする
+セキュリティスクリプトを書くことができるようになります。
+最も普通のチェック方法は、セキュリティスクリプトで、
+まず、find と md5 のバイナリファイルをリモートマシンに
+.Xr scp 1
+してから、
+リモートシステムのすべてのファイル
+.Pq もしくは、少なくとも /, /var, /usr パーティション!
+に対して md5 を適用するシェルコマンドを
+ssh を使ってリモートマシンで実行するものです。
+安全なマシンは、チェック結果をファイルにコピーし、前回のチェック結果と
+diff を取り
+.Pq または、安全なマシン自身のバイナリと比較する
+違いを
+毎日のレポートとしてスタッフメンバひとりひとりにメールを送ります。
+.Pp
+この種のチェックを行なうもう一つの方法として、安全なマシンに対して、
+他のマシンの主なファイルシステムを NFS export する方法があります。
+このやり方はいくらかネットワークに負荷を掛けることになりますが、
+侵入者がチェックを探知したり偽造したりすることは、
+事実上不可能になります。
+.Pp
+優れたセキュリティスクリプトは、一般ユーザやスタッフメンバのアクセス制御
+ファイル: .rhosts, .shosts, .ssh/authorized_keys など、MD5 での精細な
+チェックから洩れそうなファイルの変更をチェックします。
+.Pp
+優れたセキュリティスクリプトは、すべてのファイルシステム上で suid/sgid
+バイナリに対してチェックを行ない、前回のチェック結果もしくは何らかの
+基準
+.Pq "例えば、基準を週 1 回にする"
+からの差分だけでなく、
+それらの存在そのものを報告するものです。
+.Sq nosuid
+オプションを
+fstab/mount で指定することで、あるファイルシステム上の suid/sgid
+バイナリの実行機能をオフにすることができますが、root によるこれらの
+実行をオフにすることはできません。さらに、root 権限を破った者は誰でも
+自分自身で用意したバイナリをインストールすることだってできます。
+しかしながら、ユーザのディスク空間を大量に持つ場合、
+ユーザパーティションで suid バイナリとデバイス
+.Po
+.Sq nodev
+オプション
+.Pc
+を不許可にしておき、スキャンしないで済ませることも有益かもしれません。
+それでも、私ならば、少なくとも週に 1 回はスキャンする
+でしょう。というのは、タマネギのこの層の目的は侵入の検知だからです。
+.Pp
+プロセスアカウンティング
+.Po
+.Xr accton 1
+参照
+.Pc
+は、侵入後の評価の仕組みとして利用をお勧めする、
+比較的オーバヘッドの低いオペレーティングシステムの機能です。
+侵入を受けた後でも当該ファイルが無傷であるとするなら、
+侵入者が実際のところどのようにしてシステムの root を破ったかを
+追跡するのに際して特に有益です。
+.Pp
+最後に、セキュリティスクリプトはログファイルを処理するようにして、
+ログファイル自体はできるだけ安全性の高い方法で
+(リモート syslog は極めて有益になり得ます)
+生成するようにすべきです。侵入者は自分の侵入の痕跡を覆い隠そう
+としますし、ログファイルはシステム管理者が最初の侵入の時刻と方法を
+追跡してゆくために極めて重要です。
+.Sh 偏執狂的方法
+.Pp
+多少偏執狂的になっても決して悪いことにはなりません。原則的に、
+システム管理者は、便利さに影響を与えない範囲でいくつでもセキュリティ
+機能を追加することができます。また、いくらか考慮した結果、便利さに
+影響を与えるセキュリティ機能を追加することもできます。
+.Sh サービス不能攻撃 (D.O.S attack) についての特記事項
+.Pp
+このセクションではサービス不能攻撃を扱います。サービス不能攻撃は、普通は、
+パケット攻撃です。ネットワークを飽和させる最先端の偽造パケット
+.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.  
-.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.
-.Pp
-Syslogd can be attacked directly and it is strongly recommended that you use
-the -s option whenever possible, and the -a option otherwise.
-.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.
-.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 ).
-.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.
-.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.
+普通に見られるサービス不能攻撃に、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 には、
+.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 は直接攻撃される可能性があるので、可能ならば
+.Fl s
+オプションを用いることを強く推奨します。これができないなら、
+.Fl a
+オプションを使って下さい。
+.Pp
+tcpwrapper の逆 identd などの接続返し
+.Pq connect-back
+を行なうサービスに
+ついては十分注意を払うようにするべきです。これらは直接攻撃を食らう可能性が
+あります。こういう事情があるので、tcpwrapper の逆 ident 機能を使おうとは
+思わないのが一般的なところです。
+.Pp
+境界ルータのところでファイアウォールを設けて、外部からのアクセスに対して
+内部サービスを防御することは実によい考えです。この考え方は、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
+また別のありふれたサービス不能攻撃として、踏み台攻撃
+.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
+偽造パケット攻撃は、カーネルの経路情報キャッシュに過負荷を生じさせるために
+用いられることもあります。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 ,
 .Xr find 1 ,
 .Xr kerberos 1 ,
 .Xr md5 1 ,
 .Xr ssh 1 ,
 .Xr sshd 1 ,
 .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
diff --git a/ja/man/man8/pam.8 b/ja/man/man8/pam.8
index 985142f72d..2edcce772e 100644
--- a/ja/man/man8/pam.8
+++ b/ja/man/man8/pam.8
@@ -1,277 +1,282 @@
 .\" 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 名称
 
 PAM \- プラグ可能認証モジュール群
 
 .SH 書式
 .B /etc/pam.conf
 .sp 2
 .SH 解説
 
 本マニュアルの目的は、
 .B PAM
 のクイックイントロダクションです。
 更なる情報は、
 .B "Linux-PAM system administrators' guide"
 を御覧ください。
 
 .sp
 .BR PAM
 は、システム上でアプリケーション (サービス) の認証作業を行う
 ライブラリシステムです。
-本ライブラリが提供する
+本ライブラリは、
 一般的な不変のインタフェース 
-(アプリケーションプログラミングインタフェース - API) は、
+(アプリケーションプログラミングインタフェース - API) を提供します。
 .RB ( login "(1) "
 や
-.BR su "(1)) "
-のような特権許可プログラムの標準の認証作業の実行を遅らせます。
+.BR su "(1) のような) "
+特権許可プログラム
+がこの API に従うことで、
+標準の認証作業を遂行するようになります。
 
 .sp
-PAM アプローチの基本機能は、認証の種類を動的に設定可能とすることです。
+PAM アプローチの基本的な特徴は、認証作業の性質を動的に設定可能とすることです。
 言い換えると、個々のサービス提供アプリケーションがユーザを認証する方法を、
 システム管理者は自由に選択できます。
 この動的設定は、単一の
 .BR PAM
 設定ファイル
 .BR /etc/pam.conf
 の内容で設定されます。
 また、ディレクトリ
 .B /etc/pam.d/
 に個々の設定ファイルを置くことで、設定を行うこともできます。
 .IB "このディレクトリがあると " PAM " は "
 .BI /etc/pam.conf " を無視します。"
 
 .sp
 このマニュアルが対象とするシステム管理者にとっては、
 .BR PAM
 ライブラリの内部動作を理解することは最重要ではありません。
 理解すべき重要なことは、設定ファイルがアプリケーション
 .RB ( サービス )
 と実際に認証作業を行うプラグ可能認証モジュール
 .RB ( PAM )
 との間の接続を
 .I 定義する
 ことです。
 
 .sp
 .BR PAM
 は、
 .I 認証
 作業を次の 4 個の独立した管理グループに分割します:
 .BR "account" " management (アカウント管理); "
 .BR "auth" "entication management (認証管理); "
 .BR "password" " management (パスワード管理); "
 .BR "session" " management (セッション管理)。"
 (設定ファイルでグループを表すために使用する短縮形を目立たさせています。)
 
 .sp
 簡単に言うと、これらのグループは、
-制限されたサービスに対する典型的なユーザ要求の異なった側面の面倒をみています。
+それぞれ、
+ある制限されたサービスに対する典型的なユーザ要求が持つ、異なった側面の
+面倒をみています。
 
 .sp
 .BR account " - "
 アカウント証明型のサービスを提供します。
-「ユーザのパスワードが無効になったか？」
-「このユーザが要求するサービスにアクセスを許されているか？」
+「ユーザのパスワードが期限切れになったか？」
+「このユーザは、要求するサービスにアクセスを許されているか？」
 といった事柄を扱います。
 
 .br
 .BR auth "entication - "
-ユーザが名乗っている人物であることを確定します。
-典型的には、ユーザが満すべき「挑戦 - 応答」の要求で実現されます。
-例えば「あなたが名乗っているその人であるなら、
+ユーザが名乗っている人物本人であることを確定します。
+この確定は、通常は、ユーザが満すべき「挑戦 - 応答」の要求で実現されます。
+例えば「あなたが名乗っているその人本人であるなら、
 あなたのパスワードを入力してください。」が該当します。
 全部の認証がこの型であるわけではなく、
 (スマートカードや生物測定学デバイスなどを使用する)
 ハードウェアベースの認証方法があり、
 適切なモジュールを使用することで、
 より標準的な認証アプローチをシームレスに置き換え可能です -
 これが
 .BR PAM
 の柔軟性です。
 
 .br
 .BR password " - "
 このグループの責任は、認証機構を更新することです。
-典型的には、このようなサービスは
+このようなサービスは
 .BR auth
-グループのサービスと強力な結び付きがあります。
+グループのサービスと強く結び付いているのが普通です。
 認証機構によっては、自己の更新をこの機能に任せているものがあります。
-標準の UN*X のパスワードベースのアクセスは、明かな例です。
+標準の UN*X のパスワードベースのアクセスは、明らかな例です。
 「代わりのパスワードを入力してください。」がこれに該当します。
 
 .br
 .BR session " - "
 このグループの仕事は、サービス提供の前後に実行されるべきことをカバーします。
 このような作業には、認証記録の維持と、
 ユーザのホームディレクトリのマウントが含まれます。
-開始時と終了時にモジュールへのフックを提供することにより、
-ユーザが利用可能なサービスに影響を与えますので、
+開始時と終了時に
+ユーザが利用可能なサービスに影響を与える
+モジュールへのフックを提供するので、
 .BR session
 管理グループは重要です。
 
 .SH 設定ファイル
 
 .BR PAM
 を意識した特権許可アプリケーションは、
 開始時に PAM-API への取り付けを起動します。
 この起動により多くの作業が行われますが、
 最重要事項は設定ファイル
 .BR /etc/pam.conf
 の読み込みです。
 これは、
 .BR /etc/pam.d/
 ディレクトリの内容であることもあります。
 
-これらのファイルは、サービスが要求する認証作業を行う
+これらのファイルは、このサービスが要求する認証作業を行う
 .BR PAM
-と、個々の
+の一覧と、個々の
 .BR PAM
-が失敗したときの PAM-API の適切な動作をリストします。
+が失敗したときの PAM-API の適切な動作の一覧をリストします。
 
 .sp
 .B /etc/pam.conf
 設定ファイルの文法は次の通りです。
 ファイルはルールのリストから構成されます。
-個々のルールは典型的には単一行ですが、
+個々のルールは普通は単一行ですが、
 `\\<LF>' で行末をエスケープすることで複数行に渡ることが可能です。
 コメントは、前に `#' マークを置き、行末まで続きます。
 
 .sp
 各ルールは、空白で区切ったトークンの集合です。
 最初の 3 つは大文字小文字を区別します:
 
 .sp
 .br
 .BR "   service  type  control  module-path  module-arguments"
 
 .sp
 .B /etc/pam.d/
 ディレクトリ中のファイルの文法は、
 .I service 
 フィールドが無い以外は同じです。
 この場合、
 .I service
 は
 .B /etc/pam.d/
 ディレクトリ中のファイルの名前です。
 このファイル名は小文字であることが必要です。
 
 .sp
 .BR PAM
 の重要機能は、
 ある認証作業用に多くの PAM のサービスを組合せる目的で、多くのルールを
 .I 積み重ね可能
 ということです。
 
 .sp
 .BR service
-は、典型的には対応するアプリケーションの親しみのある名前です。
+は、普通は、対応するアプリケーションの親しみのある名前です。
 .BR login
 や
 .BR su
 は良い例です。
-.BR service " の名前 " other
+.BR service " 名 " other
 は
 .I デフォルト
 ルールを与えるために予約されています。
 現在のサービスに関して言及する行のみが
 (そのような行が存在しない場合は
 .BR other
 エントリが)、指定したアプリケーションに関連付けられます。
 
 .sp
 .BR type
-は、ルールが対応する管理グループです。
-後続するモジュールがどの管理グループに関連付けられるべきかを
+は、そのルールに対応する管理グループです。
+後続するモジュールをどの管理グループに関連付けるべきかを
 指定するために使用されます。
 有効なエントリは
 .BR account "; "
 .BR auth "; "
 .BR password "; "
 .BR session
 です。
 これらのトークンの意味は前述してあります。
 
 .sp
 第 3 のフィールド
 .BR control
 は、PAM-API がこの認証作業に失敗したときにどうすべきかを示します。
 有効な
 .BR control
 の値は次の通りです。
 .BR requisite
-- この PAM が失敗すると、認証処理は即時停止します;
+- この PAM が失敗すると、認証処理は即ちに終了します;
 .BR required
 - この PAM が失敗すると、究極的には PAM-API は失敗を返しますが、
 それはこの
 .RB "(" service
 および
 .BR type
-の) 積み重なっているモジュールの残りを起動した後です;
+の) 積み重なっているモジュールの残りが呼び出されたあとです;
 .BR sufficient
 - この種のモジュールが成功すると、
 モジュールの積み重ねの認証条件を満します
 (これより前の
 .BR required
 モジュールが失敗していた場合、このモジュールの成功は
 .I 無視
 されます);
 .BR optional
 - この
 .BR service "+" type
 に関連付けられているモジュールの積み重ねにおける唯一のモジュールである
 場合のみ、このモジュールの成否は意味を持ちます。
 
 .sp
 .BR module-path
 - アプリケーションが使用する PAM の完全なファイル名です。
 
 .sp
 .BR module-arguments
 - 空白で区切られたトークンのリストであり、
 指定した PAM の特定の動作を修正するために使用可能です。
 引数については、個々のモジュールについて記述されているでしょう。
 
 .SH 関連ファイル
 .BR /etc/pam.conf " - 設定ファイル。"
 .br
 .BR /etc/pam.d/ " - "
 .BR PAM
 の設定ディレクトリ。本ディレクトリが存在する場合、
 .B /etc/pam.conf
 ファイルは無視されます。
 .br
 .BR /usr/lib/libpam.so.X " - 動的ライブラリ。"
 .br
 .BR /usr/lib/pam_*.so " - PAM。
 
 .SH エラー
 ライブラリの
 .BR PAM
 システムが発生する典型的なエラーは、
 .BR syslog "(3)"
 に書き込まれます。
 
 .SH 準拠
 DCE-RFC 86.0, October 1995.
 .br
-現在 DCE-RFC 委員会で考察されている追加機能があります。
+現在 DCE-RFC 委員会で検討されている追加機能も含まれています。
 
 .SH バグ
 .sp 2
 知られているものはありません。
 
 .SH 関連項目
 
 .BR "システム管理者用" "、"
 .BR "モジュール開発者用" "、"
 .BR "アプリケーション開発者用
 の、3 つの
 .BR Linux-PAM
 ガイド。
diff --git a/ja/man/man8/usbdevs.8 b/ja/man/man8/usbdevs.8
index e25e7808da..fd3088ef0b 100644
--- a/ja/man/man8/usbdevs.8
+++ b/ja/man/man8/usbdevs.8
@@ -1,68 +1,68 @@
 .\" %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.
 .\"
 .\" Author: Lennart Augustsson
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
 .\" 1. Redistributions of source code must retain the above copyright
 .\"    notice, this list of conditions and the following disclaimer.
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
 .\" 3. All advertising materials mentioning features or use of this software
 .\"    must display the following acknowledgement:
 .\"        This product includes software developed by the NetBSD
 .\"        Foundation, Inc. and its contributors.
 .\" 4. Neither the name of The NetBSD Foundation nor the names of its
 .\"    contributors may be used to endorse or promote products derived
 .\"    from this software without specific prior written permission.
 .\"
 .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
 .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 .\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS 
 .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 .\" POSSIBILITY OF SUCH DAMAGE.
 .\"
 .Dd July 12, 1998
 .Dt USBDEVS 8
 .Os
 .Sh 名称
 .Nm usbdevs
 .Nd システムに接続されている USB 機器を表示する
 .Sh 書式
 .Nm
 .Op Fl a Ar addr
 .Op Fl f Ar dev
 .Op Fl v
 .Sh 解説
 .Nm
-は、システムに接続されているすべての USB 機器を、
-それぞれの機器に関する多少の情報と共に表示します。
+は、システムに接続されているすべての USB 機器の一覧を、
+それぞれの機器に関するいくらかの情報とともに表示します。
 各行のインデントは root からの距離を示しています。
 .Pp
 オプションは次の通りです:
 .Bl -tag -width Ds
 .It Fl a Ar addr
 指定されたアドレスにある機器の情報のみを表示します。
 .It Fl f Ar dev
 指定された USB コントローラの情報のみを表示します。
 .It Fl v
 冗長になります。
 .El
 .Sh 関連項目
 .Xr usb 4
 .Sh 歴史
 コマンドは
 .Nx 1.4
 で登場しました。
diff --git a/ja_JP.eucJP/man/man5/isdnd.rc.5 b/ja_JP.eucJP/man/man5/isdnd.rc.5
index b75ce8ea38..a506d95649 100644
--- a/ja_JP.eucJP/man/man5/isdnd.rc.5
+++ b/ja_JP.eucJP/man/man5/isdnd.rc.5
@@ -1,681 +1,682 @@
 .\"
 .\" Copyright (c) 1997, 1998 Hellmuth Michaelis. All rights reserved.
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
 .\" 1. Redistributions of source code must retain the above copyright
 .\"    notice, this list of conditions and the following disclaimer.
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
 .\"
 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" 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]
 .\"
 .\" WORD: exchange	交換局
 .\" WORD: subscribe	(AOCD サービス等を) 申し込んでいる
 .Dd October 27, 1998
 .Dt isdnd.rc 5
 .Sh 名称
 .Nm isdnd.rc
 .Nd isdn4bsd ISDN 接続管理デーモンの設定ファイル書式
 .Sh 解説
 (コマンドラインで別のものを指定しない限り) ファイル
 .Pa /etc/isdn/isdnd.rc
 は、
 .Xr isdnd 8
 ISDN 接続管理デーモンの実行時設定を格納します。
 本デーモンは、isdn4bsd パッケージの一部です。
 .Pp
 設定ファイルには、第 1 桁から始まるキーワードが複数含まれます。
 キーワードの後には、1 個以上の空白・タブ、単一の等号、1 個以上の空白・タブ、
-キーワード依存のパラメータ値が続きます。
+キーワード依存のパラメータ値と続きます。
 .Pp
 文字 '#' で開始する行はコメント行として扱われます。
 .Pp
 ブール値指定を要求するキーワードに対しては、真を
 .Em yes
 または
 .Em on
 で与え、偽を
 .Em no
 または
 .Em off
 で与えます。
 .Pp
 設定ファイルには、単一の
 .Em システム
 セクションと 1 個以上の
 .Em エントリ
 セクションが含まれます。
 .Em システム
 セクションでは、デーモンの操作に関するパラメータや
 単一のリモート接続に関連付けられないパラメータを設定可能です。
 .Em エントリ
 セクションでは、
 単一のリモート接続に直接関連付けられたパラメータを設定可能です。
 .Pp
 次のキーワードを
 .Nm isdnd
 は理解します:
 .Pp
 .Bl -tag -width system -compact
 
 .It Li system
 本キーワードにより、システム設定セクションが開始します。
 パラメータを伴ってはなりませんし、1 度のみ使用可能です。
 本キーワードは必須です。
 次のキーワードは、システム設定セクション内で有効です:
 .Bl -tag -width useacctfile -compact
 
 .It Li acctall
 本パラメータを
 .Em on
 に設定すると、
 ローカルサイトが課金されてない場合や、
 課金情報が利用不能だったり課金情報を申し込んでいない場合でも、
 アカウンティング情報が書き込まれます。(省略可能)
 
 .It Li acctfile
 キーワード
 .Em useacctfile
 (後述) が
 .Em on
 に設定されたときに使用されるアカウンティングファイルの名前を指定します。
 本キーワードを指定しないと、システムデフォルトが使用されます。(省略可能)
 
 .It Li aliasing
 本パラメータが
 .Em on
 に設定されると、電話番号から名前へのエイリアス処理が有効にされます (後述の
 .Em aliasfile
 キーワードも参照)。デフォルトは off です。(省略可能)
 
 .It Li aliasfile
 .Em aliasing
 キーワードによりエイリアス処理が有効にされたときに
 .Xr isdntel 1
 ユーティリティと共有される、
 電話番号から名前へのエイリアスデータベースファイルの名前を指定します。
 (省略可能)
 
 .It Li isdntime
 本パラメータが
 .Em on
 に設定されると、(提供されるならば) 交換局から得られる日付/時刻情報を
 ログファイルに書き込みます。デフォルトは off です。(省略可能)
 
 .It Li monitor-allowed
 本パラメータが
 .Em on 
 または
 .Em yes
 に設定されると、
 ローカルマシンまたはリモートマシンを介した監視が有効になります。
 本パラメータは省略可能であり、デフォルトで
 .Em off
 に設定されます。
 
 .It Li monitor-port
 リモート監視用の TCP ポート番号を設定します。
 本整数パラメータは省略可能であり、デフォルトでポート 451 に設定されます。
 
 .It Li monitor
 本キーワードは、ローカルソケット名または、
 リモート監視用にホストまたはネットワークを指定します。
 .Em monitor 
 の指定は次のいずれかです:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar ローカル (UNIX ドメイン) ソケット名
 文字 "/" で開始する必要があります。例: /var/run/isdn-monitor
 .It Ar ドット付き 4 つ組のホスト指定
 例: 192.168.1.2
 .It Ar ドット付き 4 つ組のネットワークアドレスとネットマスク
 例: 192.168.1.0/24
 .It Ar 解決可能なホスト名
 例: localhost
 .It Ar 解決可能なネットワーク名とネットマスク
 例: up-vision-net/24
 .El
 
 .It Li monitor-access
 本キーワードは、以前使用した
 .Em monitor
 キーワードのアクセス権限を指定します。
 サポートされているアクセス権限は次の通りです:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar fullcmd
 .It Ar restrictedcmd
 .It Ar channelstate
 .It Ar logevents
 .It Ar callin
 .It Ar callout
 .El
 
 .It Li ratesfile
 料金ファイルの名前を指定します。
 本キーワードが省略された場合、システムデフォルトが使用されます。(省略可能)
 
 .It Li regexpr
 本キーワードは、正規表現を指定するために使用されます。
-1 度より多く指定することが可能であり、
-コンパイル時に依存する値まで指定可能です
-(現在、ソースにおける MAX_RE の定義により、5 に設定されます)。
+1 度以上、コンパイル時依存の回数
+(現在、ソースにおける MAX_RE の定義では 5 回)
+まで指定することが可能です。
 .Pp
 指定した全正規表現は実行時にログ文字列と比較され、
 マッチした場合には、ログテキストをパラメータとしてプログラムが実行されます
 (後述のキーワード
 .Em regprog
 も参照)。
 .Pp
 正規表現の指定方法については、
 .Xr re_format 7
 と
 .Xr regex 3
 を参照してください。
 .Em 拡張
 正規表現の書式がサポートされています。
 .Pp
 ヒント: 設定ファイルのパーザが不適切に解釈することを避けるために、
 式を適切にクォートする必要があるかもしれません。
 (省略可能)
 
 .It Li regprog
 本キーワードは、対応する正規表現がログ文字列にマッチした場合に実行される、
 プログラムの名前を指定するために使用されます。
 .Nm isdnd
 は、パス
 .Pa /etc/isdn
 以下でプログラムを見付けられるものと期待します。
 このパスは、本キーワードのパラメータとして指定された文字列の前に付けられます。
 (省略可能)
 
 .It Li rtprio
 .Nm isdnd
-が実行されるリアルタイム優先度を、整数値範囲 0 〜 31 で指定します。
+が実行されるリアルタイム優先度を、0 〜 31 の範囲の整数値で指定します。
 0 は最高の優先度です。
 本キーワードは省略可能です。
 指定しない場合、
 .Nm isdnd
 の処理優先度はまったく修正されません。(
 .Xr rtprio 1 
 も参照)。
 本キーワードは、
 .Nm
 を -DUSE_RTPRIO 付きでコンパイルした場合にのみ利用可能です。
 
 .It Li useacctfile
 本パラメータが
 .Em on
 に設定された場合、(利用可能な場合) 課金情報とアカウンティング情報が
 アカウンティングファイルに書き込まれます。(省略可能)
 
 .El
 
 .It Li entry
 本キーワードにより、単一の設定エントリが開始します。
 パラメータを伴ってはなりません。
 本キーワードは、少なくとも 1 度は使用する必要があります。
 次のキーワードは、エントリセクション内で有効です:
 .Bl -tag -width unitlengthsrc -compact
 
 .It Li answerprog
-本キーワードは、内向き電話接続が設定エントリにおいて
+本キーワードは、着信電話接続が設定エントリにおいて
 .Em answer
 を指定した場合に実行される、プログラムの名前を指定するために使用されます。
 デフォルト名は
 .Em answer
 です。
 .Nm isdnd
 は、パス
 .Pa /etc/isdn
 以下でプログラムを見付けられるものと期待します。
 このパスは、本キーワードのパラメータとして指定された文字列の前に付けられます。
 (省略可能)
 
 .It Li alert
-呼び出しを受け付ける前に待つ秒数を指定するために使用します。
-本キーワードは、内向き電話呼び出し (dialin-reaction = answer)
+呼 (call) を受け付ける前に待つ秒数を指定するために使用します。
+本キーワードは、電話着呼 (dialin-reaction = answer)
 のためにのみ指定可能です。
-応答マシンが実行を開始する前に、
-電話の内向き呼び出しを受け付ける機会を持つために、使用します。
+留守番マシンが実行を開始する前に、
+電話の着呼 (incoming call) を受け付ける機会を持つために使用します。
 本パラメータの最小値は 5 秒であり、パラメータの最大値は 180 秒です。
 (省略可能)
 
 .It Li b1protocol
 本接続に使用される B チャネルのレイヤ 1 プロトコルです。
 本キーワードは必須です。
 現在設定可能な値は次の通りです:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar hdlc
 HDLC フレーミング。
 .It Ar raw
 フレーミングを行わない (電話通信のために使用)。
 .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
 本キーワードは、どのタイプのダイヤルアウトモードが使用されるかを設定します。
 本キーワードは必須です。
 現在サポートされているパラメータは次の通りです:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar normal
-通常動作。呼び出しを受け付けると思われるリモートサイトを呼び出します。
+通常動作。呼を受け付けると思われるリモートサイトを呼び出します。
 .It Ar calledback
 コールバック動作。
-呼び出しを拒否してから当方にコールバックするリモートサイトを呼び出します。
+呼を拒否してから当方にコールバックするリモートサイトを呼び出します。
 .El
 
 .It Li dialrandincr
 ダイヤル時または再ダイヤル時、本パラメータが
 .Em on
 に設定されていると、
 ダイヤル再試行時間に乱数 (現在 0 〜 3 秒) が加えられます。
 2 つのサイトが同期してダイヤルしてしまい、
 他方もダイヤルしているために双方がダイヤルする度にビジーを検出するという機会を
 最小化します。
 
 .It Li dialretries
-ダイヤルを諦める前に再試行する回数です。(省略可能)
+ダイヤルをあきらめる前に再試行する回数です。(省略可能)
 
 .It Li direction
-本キーワードは、内外向き・内向きのみ・外向きのみのいずれの接続が可能であるかを
+本キーワードは、発信着信・発信のみ・着信のみのいずれの接続が可能であるかを
 設定するために使用します。
 本キーワードは省略可能であり、デフォルトは
 .Em inout
 です。
 .Pp
 現在サポートされているパラメータは次の通りです:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar inout
 通常動作。接続の確立は、リモートからでもローカルからでも可能です。
 .It Ar in
-内向き接続のみ可能です。
+着信接続のみ可能です。
 .It Ar out
-外向き接続のみ可能です。
+発信接続のみ可能です。
 .El
 
 .It Li downtries
 失敗する試行回数を指定するために使用します。
-失敗する試行 (=再試行サイクルです!) をこの回数だけ行った後、
+試行 (=再試行サイクルです!) がこの回数だけ失敗すると、
 インタフェースを (
 .Em downtime
 秒だけ) 無効にします。
 (詳細はキーワード
 .Em usedown
 を参照)。本キーワードは省略可能です。
 
 .It Li downtime
 .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) を指定すると本機能を無効化します。これがデフォルト値です。
 本機能は
 .Xr i4bipr 4
 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
 ローカルサイトからダイヤルアウトする場合に使用される、ローカルの電話番号。
 リモートサイトに対してダイヤルアウトするとき、
 ここで指定した番号が
 .Em "発番号情報要素 (Calling Party Number Information Element)"
 に埋め込まれます。
 .Pp
-本キーワードは、ipr ユーザランドインタフェース用のために必須です。
+本キーワードは、ipr ユーザランドインタフェースのために必須です。
 .\" 原文の .em (Execute Macro) は、引数無しの場合効果が無いので削除
 .\" horikawa@jp.freebsd.org 1999/01/19
 
 .It Li local-phone-incoming
-内向き呼び出しの宛先を確認するために使用する、ローカルの電話番号です。
+着呼の宛先を確認するために使用する、ローカルの電話番号です。
 リモートサイトがダイヤルインするとき、
 リモートサイトの希望接続先がローカルサイトであることを確認するために、
 本番号を使用します。
 この値は、電話交換局から得られる
 .Em "着番号情報要素 (Called Party Number Information Element)"
 と比較されます。
 .Pp
 本キーワードは ipr インタフェースのために必須です。
 
 .It Li name
-本設定エントリにシンボルによる名前を定義します。
+その設定エントリにシンボルによる名前を定義します。
 全画面表示においてこの名前を使用して
-リモートサイトへのリンクを識別し易くすることと、
+リモートサイトへのリンクを識別しやすくすることと、
 アカウンティングに使用することを目的としています。(必須)
 
 .It Li ratetype
 料金ファイル中の、使用する料金エントリ。(省略可能)
 .br
 例えば、
 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
 
 .It Li remote-phone-dialout
 ローカルサイトからダイヤルアウトする場合に使用される、リモートの電話番号。
 リモートサイトに対してダイヤルアウトするとき、
 ここで指定した番号が
 .Em "着番号情報要素 (Called Party Number Information Element)"
 に埋め込まれます。
 .Pp
-本キーワードは、ipr インタフェース用のために必須です。
+本キーワードは、ipr インタフェースのために必須です。
 .\" 原文の .em (Execute Macro) は、引数無しの場合効果が無いので削除
 .\" horikawa@jp.freebsd.org 1999/01/19
-どれかひとつが成功するまでいくつかの番号に対して試行させるために、
-複数回指定可能です。
+複数回指定して、
+どれかひとつが成功するまでいくつかの番号に対して試行させることもできます。
 
 .It Li remote-phone-incoming
-内向き呼び出しを確認するために使用する、リモートの電話番号です。
+着呼を確認するために使用する、リモートの電話番号です。
 リモートサイトがダイヤルインするとき、
 ローカルシステムに対して接続する権限がある
 正しいリモートサイトであることを確認するために、
 本番号を使用します。
 この値は、電話交換局から得られる
 .Em "発番号情報要素 (Calling Party Number Information Element)"
 と比較されます。
 .Pp
 本キーワードは ipr インタフェースのために必須です。
 .Pp
-本キーワードを、ワイルドカードパラメータ '*' として、
+本キーワードにワイルドカードパラメータ '*' を渡して、
 誰もがダイヤルイン可能とできます。
 
 .It Li unitlength
 秒数による課金単位の長さ。
-アイドルタイムとともに使用して、接続をいつハングアップするのかを決定します。
+アイドル時間とともに使用して、いつ接続を切るのかを決定します。
 (省略可能)
 
 .It Li unitlengthsrc
 本キーワードは、ショートホールドモードにおいて
 .Xr isdnd 8
 がどこから unitlength を取得するかを指定します。
 現在設定可能な値は次の通りです:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar none
 unitlength は、どこにも指定されません。
 .It Ar cmdl
 コマンドラインで指定される unitlength を使用します。
 .It Ar conf
 設定ファイルでキーワード
 .Em unitlength
 で指定される 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
 
 .It Li usrdevicename
 ISDN B チャネルデータをユーザランドにインタフェースするために使用する、
 ユーザランドインタフェースを指定します。
 本キーワードは必須です。
 本キーワードは次のパラメータを受け付けます:
 .Pp
 .Bl -tag -width Ds -compact -offset
 .It Ar ipr
 本パラメータは raw HDLC IP over ISDN インタフェースを設定します。
 .It Ar isp
 本パラメータは shyncronous PPP over ISDN インタフェースを設定します。
 .It Ar rbch
 本パラメータは Raw B CHannel アクセスインタフェースを設定します。
 .It Ar tel
 ISDN 電話通信。
 .El
 
 .It Li usrdeviceunit
 usrdevicename が指定するデバイスの、ユニット番号を指定します。
 .\" 原文の .em (Execute Macro) は、引数無しの場合効果が無いので削除
 .\" horikawa@jp.freebsd.org 1999/01/19
 .\" 文法もちょっとヘンですね。
 .\" Specifies the unit number for the with the
 .\" .em
 .\" usrdevicename
 .\" specified device.
 
 .It Li usedown
 エントリセクションにおいて、キーワード
 .Em downtries
 と
 .Em downtime
-を使用可能とするために使用します。
+を有効にするために使用します。
 (回線ビジーの場合等) 遷移に失敗する場合に、
-過度のダイヤルアクティビティを避けるために、
+過度のダイヤル動作を避けるために、
 .Nm isdnd
 が IP インタフェースの有効・無効を動的に切り替えるために使用します。
 本パラメータは省略可能であり、デフォルトで
 .Em off
 に設定されます。
 
 .It Li connectprog
 接続が確立してアドレス交渉が完了した後 (すなわち接続を使用可能となった後)、
 毎回実行するプログラムを指定します。
 .Nm isdnd
 は、パス
 .Pa /etc/isdn
 以下でプログラムを見付けられるものと期待します。
 このパスは、本キーワードのパラメータとして指定された文字列の前に付けられます。
 (省略可能)
 
 .It Li disconnectprog
 接続がシャットダウンされた後、毎回実行するプログラムを指定します。
 .Nm isdnd
 は、パス
 .Pa /etc/isdn
 以下でプログラムを見付けられるものと期待します。
 このパスは、本キーワードのパラメータとして指定された文字列の前に付けられます。
 (省略可能)
 
 .El
 .El
 
 .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 (ゼロ) 以上であることが必要です
 。
 
 .Bd -literal
 
 |<unchecked window>|<checkwindow>|<safetywindow>|
 |                  |             |              |
 +------------------+-------------+--------------+
 |                  |             |              |
 |                  |<-idle-time->|<earlyhangup->|
 |<--------------unitlength--------------------->|
 
 .Ed
 
 チェック対象外ウィンドウ (uncheked window) は、
 (unitlength - (idle-time + earlyhangup)) の長さであり、
 この間アイドルチェックはされません。
 チェック対象外ウィンドウが終ると、idle-time の期間、
 回線にトラフィックが無いかチェックされます。
 チェックウィンドウ (check-window) の期間にトラフィックが検出された場合、
 次の単位 (unit) の先頭から同じ手続きが再度開始されます。
-チェックウィンドウ (check-window) の期間トラフィックが検出されない場合、
+チェックウィンドウの期間トラフィックが検出されない場合、
 チェックウィンドウ終了時に回線が閉じられます、
 .Pp
 注釈:
 .Em unitlength
 は
 .Em idletime-outgoing
 と
 .Em earlyhangup
 の合計よりも大きいことが必要 (!) です!
 
 .El
 .El
 
 .Pp
 
 .Sh 関連ファイル
 .Bl -tag -width /etc/isdn/isdnd.rc -compact
 .It Pa /etc/isdn/isdnd.rc
 .Nm isdnd
 ISDN デーモンのデフォルトの設定ファイル。
 
 .Sh 関連項目
 .Xr isdnd 8
 .Xr isdnmonitor 8
 .Xr regex 3
 .Xr re_format 7
 
 .Sh 作者
 .Xr isdnd 8
 デーモンと本マニュアルページは Hellmuth Michaelis が書きました。
 彼の連絡先は、hm@kts.org です。
diff --git a/ja_JP.eucJP/man/man7/security.7 b/ja_JP.eucJP/man/man7/security.7
index 32632118d6..534e92d12a 100644
--- a/ja_JP.eucJP/man/man7/security.7
+++ b/ja_JP.eucJP/man/man7/security.7
@@ -1,447 +1,634 @@
 .\" Copyright (c) 1998, Matthew Dillon.  Terms and conditions are those of
 .\" the BSD Copyright as specified in the file "/usr/src/COPYRIGHT" in
 .\" 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.
-.Pp
-Security concerns can be split up into several categories:
+システムは昔からマルチユーザに対応しています。セキュリティの仕組みを
+組み込んで維持することで、ユーザを
+.Sq 正直に
+し続ける仕事は、システム管理者の最も大きな責務の一つでしょう。マシンは、
+管理者が設定しただけのセキュリティしか示しません。セキュリティに関する
+問題は、むしろ、便利さを求める人間との競合問題です。一般に、
+.Ux
+システムは莫大な数のプロセスを同時に実行させることも、また、その多くを
+サーバとして動作させることもできます。これは、外部の何者かが
+接続してきて、サーバプロセスと会話することができるということを
+意味します。昨日までのミニコンピュータとメインフレームは、今日では
+デスクトップコンピュータとなり、かつ、それらはネットワークで結ばれて
+インターネットと接続されるようになりました。これにより、セキュリティは
+昔と比べてはるかに大きな問題となっています。
+.Pp
+セキュリティに関する問題は、いくつかのカテゴリに分類することができます。
 .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.
-.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.
-.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.
-.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.
-.Pp
-Security remedies are always implemented in a multi-layered 'onion peel' 
-approach and can be categorized as follows:
+サービス不能攻撃とは、マシンから必要な資源を奪う行為です。
+サービス不能攻撃は、普通は、そのマシンで実行されるサーバや
+ネットワークスタックを圧倒して、マシンを使えなくしたりクラッシュさせようと
+するような力任せの仕組みです。サービス不能攻撃のいくつかは、
+ネットワークスタックのバグを利用して、パケット一つでマシンを
+クラッシュさせようとします。後者は、
+カーネルにバグ修正を施すことによってのみ修正することができます。
+サーバプロセスに対する攻撃は、サーバのオプションを適切に指定して、
+逆境状況のシステムにおいて、サーバプロセスが引き起こす負荷に限界を設けることで
+修正することができます。これらに比べると、ネットワークへの力任せの攻撃への
+対応はずっと難しくなります。たとえば、偽造パケットによる攻撃
+.Pq spoof-packet attack
+は、インターネットからシステムを切り離す以外の方法では、抑止することは
+ほとんど不可能です。
+.Pp
+ユーザアカウントを危険に晒すことは、サービス不能攻撃よりは多少はありふれた
+ものです。このご時勢でも、システム管理者の多くは、自分たちのマシンで
+標準の telnetd, rlogind, rshd, ftpd サーバを実行させています。これらの
+サーバは、デフォルトでは、暗号化されたコネクション上で動作していません。
+その結果、抱えているユーザ数が標準的な大きさならば、リモート
+.Pq そのシステムにログインするのに最も普通で便利な場所
+からログインしているユーザのうち一人以上は、パスワードを覗き見られて
+しまうでしょう。
+システム管理者が注意深いならば、たとえログインが成功していたとしても、
+リモートアクセスログをときどき解析して、疑わしいソースアドレスを探すものです。
+.Pp
+ひとたび攻撃者がユーザアカウントへのアクセス権を入手すると、攻撃者が
+root の権限を破る可能性があることを仮定するべきです。しかし、
+セキュリティを十分保ち、手入れの行き届いたシステムにおいては、
+あるユーザアカウントへのアクセスが可能となっても、攻撃者に必ずしも
+root へのアクセス権を与えるとは限らないのが現実です。この違いは重要です。
+というのは、root へのアクセス権がなければ、一般的に、攻撃者は自分の
+侵入の痕跡を隠蔽することができませんし、そのユーザのファイルを消して
+マシンをクラッシュさせることができるのがせいぜいで、他のユーザの
+ファイルには手出しできません。
+.Pp
+システム管理者は、あるマシン上で root の権限を破る方法がいくつかあることを
+心しておかねばなりません。攻撃者が root のパスワードを知ってしまうかも
+しれません。攻撃者が root の権限で実行されるサーバのバグを見つけ、
+ネットワークからそのサーバへ接続して root の権限を破ることができるかも
+しれません。ひとたびユーザアカウントを破ると、ユーザアカウントから
+root の権限を破ることが可能であるバグを持つ suid-root プログラムの
+存在を、攻撃者は知っているかもしれません。
+.Pp
+セキュリティを改善する方法は、常に、
+.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
-.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.
-.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.
-.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.
-.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
-.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!
-.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.
-.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.
-.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
-.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
-.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.
-.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
-.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.
-.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
-.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.
-.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.
-.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.
-.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.
-.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.
-.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
-.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
-.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.  
+.Sh root アカウントとスタッフアカウントの安全性を高める
+.Pp
+root のアカウントの安全性を確保しないうちからスタッフのアカウントの安全性を
+うんぬんしてもしかたがありません。ほとんどのシステムでは、root アカウントに
+割り当てたパスワードがひとつあります。まず最初にすべきことは、
+このパスワードは
+.Sq いつでも
+危険に晒されていると仮定することです。root アカウントの安全性を確保する
+ためには、ネットワーク越しに、あるいはどれか一般ユーザのアカウントから、
+root のパスワードを使って root アカウントにログインすることが決して
+できないことを確実にすることです。正しいパスワードが与えられようが
+与えられまいが、telnetd, rlogind, その他ログイン処理を行なうサーバ
+すべてで root でのログインを拒絶するように設定していないとするなら、
+今すぐそういうふうに設定して下さい。直接 root でログインできるのは、
+システムコンソールからだけにして下さい。ここで役に立つのが
+.Sq /etc/ttys
+ファイルです。ほとんどのシステムでは、デフォルトで安全ですが、
+優れたシステム管理者は、設定がそうなっているか常にチェックを怠らない
+ものです。
+.Pp
+システム管理者として、自分は root になれるようにしておかねばならないの
+はもちろんですから、穴をいくつか空けておきます。しかし、それらの穴を
+動作させるには、さらに追加のパスワード認証が必要であるようにして
+おきます。root でアクセス可能とする方法の一つとして、
+適切なスタッフアカウントを
+.Pq /etc/group の
+wheel グループに加えることがあります。
+wheel グループに置かれたスタッフメンバには、
+.Sq su
+を使って root になることが許されます。スタッフメンバに、
+パスワードファイルのエントリでそのまま wheel のアクセス権を
+与えてはいけません。スタッフは、
+.Sq staff
+かその類のグループに置き、その中で本当に root になる必要がある人
+だけを wheel グループに加えるようにします。残念ながら、wheel の
+仕組みだけだと、侵入者がパスワードファイルを手に入れると、攻撃者が
+破る必要があるのは root のパスワードか、wheel グループにたまたま属す
+staff アカウントの一つのパスワードだけです。wheel の仕組みは有益
+ですが、wheel グループがまったく存在しない状況と比べてそれほど
+安全なわけではありません。
+.Pp
+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
+より間接的なセキュリティの仕組みは、より制限の強いサーバから制限の弱い
+サーバへログインすることを前提としています。例えば、主マシンで、
+すべての種類のサーバを実行させている場合、ワークステーションではそれらの
+サーバを実行させてはなりません。ワークステーションの安全性を比較的
+高めておくためには、実行するサーバの数を、果てはサーバなしまで、
+できるだけ減らしておくべきです。また、パスワード防護された
+スクリーンセーバを走らせておくべきです。
+ワークステーションへの物理的アクセスが与えられたとすると、攻撃者は
+管理者が設定したいかなる種類のセキュリティをもうち破ることができるのは
+もちろんのことです。これは、管理者として考えておかねばならない決定的な
+問題ですが、システム破りの大多数は、ネットワーク経由でリモートから、
+ワークステーションやサーバへの物理的アクセス手段を持たない人々によって
+行なわれるという事実も、また、念頭に置いておく必要があります。
+.Pp
+kerberos のような方法を使うことで、スタッフアカウントのパスワードの変更
+もしくは停止を一箇所で行なうことと、スタッフメンバがアカウントを持つ
+すべてのマシンに即時にその効果を及ぼすことが可能となります。スタッフメンバの
+アカウントが危険に晒されたときに、すべてのマシンでその人のパスワードを
+即座に変更する機能を甘く見てはいけません。パスワードが分散されていると、
+N 台のマシンでパスワードを変更することは、てんやわんやの事態を招く可能性が
+あります。kerberos による再パスワード制限
+.Pq re-passwording restriction
+を課することもできます。これを使うことにより可能となることは、
+ある kerberos チケットをしばらくしてからタイムアウトにすることだけでなく、
+kerberos システムがユーザに一定期間
+.Pq 例えば、1 ヶ月に 1 回
+の後に新しいパスワードを選ぶことを要求することもできます。
+.Sh root の安全性を高める - root 権限のサーバと suid/sgid バイナリ
+.Pp
+用心深いシステム管理者は、自分に必要なサーバプロセスだけを過不足なく
+実行させるものです。第三者製のサーバはしばしばバグの温床であることに
+注意して下さい。例えば、古いバージョンの 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
+.Bx Free
+では、今では ntalkd, comsat, finger は砂場で実行させることが
+デフォルトになっています。次に砂場で実行させるべきプログラムの候補として、
+.Xr named 8
+があります。デフォルトの rc.conf ファイルには、named を砂場で実行する
+ために必要な引数がコメントアウトされた形式で含められています。新しい
+システムをインストールしているか、それとも既存のシステムを
+アップグレードして使っているかに依存しますが、砂場として使用する
+特別のユーザアカウントがインストールされていないかもしれません。用心深い
+システム管理者は研究を怠らず、可能なところではつねにサーバに砂場を仕込む
+ものです。
+.Pp
+通常、砂場で実行しないサーバが他にいくつかあります。sendmail, popper,
+imapd, ftpd などです。これらのうちいくつかには代わりがありますが、
+代わりのものをインストールするには、それだけ多くの仕事が必要になるので、
+結局これらを喜んで入れてしまいます
+.Pq 簡単度がまたも勝利を収めるわけです
+。
+これらのサーバは、root 権限で実行せねばならず、これら経由で生じる侵入の
+検出のためには、他の仕組みに依存せねばならないかもしれません。
+.Pp
+システムの 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
+ユーザアカウントは、普通、安全性を高めることが最も困難です。
+スタッフに対して、アテナイのドラコのような厳格なアクセス制限を課し、
+スタッフのパスワードを\ * で外すことができるとはいえ、管理者が持ちうる
+一般ユーザすべてのアカウントに対して同じことはできないかも知れません。
+十分な管理を保つならば、管理者は勝利し、ユーザの
+アカウントを適切な状態で安全を確保できるかもしれません。それが
+保てないならば、一般ユーザのアカウントをモニタしていっそう気を配るように
+するしかありません。一般ユーザアカウントでの ssh や kerberos の利用は、
+いろいろ問題をはらんでいます。それでも、暗号化パスワードと比較すると、
+はるかに良い解です。
+.Sh パスワードファイルの安全性を高める
+.Pp
+できるだけ多くのパスワードを\ * で外し、それらのアカウントのアクセスには
+ssh や kerberos を使うようにすることが、唯一の確実な方法です。たとえ暗号化
+パスワードファイル 
+.Pq /etc/spwd.db
+が root でのみ読み出し可能だとしても、
+たとえ root の書き込み権限が得られないにしても、侵入者がそのファイルの
+読み出しアクセス権限を得ることは可能かも知れません。
+.Pp
+セキュリティスクリプトは常にパスワードファイルの変更をチェックし、報告
+するようにすべきです (後述の「ファイルの完全性のチェック」を参照して下さい)。
+.Sh カーネルのコア、raw デバイス、ファイルシステムの安全性を高める
+.Pp
+root の権限を破ると、攻撃者はほとんど何でもできますが、
+もっと簡便なこともいくつかあります。例えば、最近のカーネルのほとんどでは、
+組み込みのパケット覗き見デバイス
+.Pq packet sniffing device
+ドライバを備えています。
+.Bx Free
+では
+.Sq bpf
+デバイスと呼ばれています。侵入者は普通、危険に晒された
+マシンでパケット覗き見プログラムを実行させようと試みます。侵入者に
+わざわざそういう機能を提供する必要はないので、ほとんどのシステムで bpf
+デバイスを組み込むべきではありません。不幸なことに、ローダブルカーネル
+モジュール 
+.Pq Loadable Kernel Module:LKM
+インタフェースと呼ばれる
+カーネル機能があります。やる気まんまんの侵入者は、LKM を使って
+自分独自の bpf もしくはその他覗き見デバイスを動作中のカーネルに
+インストールすることが可能です。
+モジュールローダを使う必要がないのであれば、カーネル設定で
+NO_LKM オプションを設定してこの機能を無効にして下さい。
+.Pp
+bpf デバイスを外し、モジュールローダを無効にしても、/dev/mem と /dev/kmem
+という悩みの種がまだ残っています。この問題に関しては、侵入者は raw
+デバイスに書き込むこともできます。この問題を避けるため、システム管理者は
+カーネルをより高い安全レベル
+.Pq securelevel
+、少なくとも安全レベル 1 で実行させる必要があります。
+sysctl を使って kern.securelevel 変数に安全レベルを設定することが
+できます。ひとたび安全レベルに 1 を設定すると、
+raw デバイスに対する書き込みアクセスは拒否され、例えば
+.Sq schg
+のような
+特別な chflags フラグが効果を発揮します。これに加えて、
+起動において重要なバイナリ・ディレクトリ・スクリプトファイルなど、
+安全レベルが設定されるまでの間に実行されるものすべてに対しても
+.Sq schg
+フラグを確実に on にしておく必要があります。この設定をやり過ぎても
+構いませんが、より高い安全レベルで動作している場合、システムの
+アップグレードがはるかに困難になります。システムをより高い安全レベルで
+実行させるようにするが、お天道さまの下にあるすべてのシステムファイルと
+ディレクトリに schg フラグを設定しないという妥協をする方法もあります。
+.Sh ファイルの完全性のチェック: バイナリ、設定ファイルなど
+.Pp
+ことここに至るとシステム管理者にできることは、
+便利度がその醜い頭を上げない程度に、
+コアシステムの設定 / 制御ファイルを防御することだけです。
+セキュリティのタマネギの最後の層はおそらく最も重要なもの、すなわち探知です。
+.Pp
+システムファイルの完全性をチェックする唯一の正しい方法は、別の、より安全な
+システム経由で行なう方法だけです。
+.Sq 安全
+なシステムを準備することは比較的
+容易です。単に、サービスを一切実行しないようにするだけです。安全なシステム
+を用いて、ssh 経由で他のシステムの root 空間にアクセスします。これは
+セキュリティの末端のように見えるかもしれません。しかし、管理者には信頼を
+どこかに置く必要があります。いきあたりばったりでサーバプロセスを
+実行するような馬鹿げたことをしない限りは、安全度の高いマシンを構築する
+ことは本当に可能です。ここで
+.Sq 安全
+という場合、物理アクセスに対する
+セキュリティをも含めて仮定していることはもちろんです。安全なマシンで、
+他のすべてのマシンに root のアクセス権限を持つものが得られると、
+「安全なマシンの上で」システムの他のマシンをチェックする
+セキュリティスクリプトを書くことができるようになります。
+最も普通のチェック方法は、セキュリティスクリプトで、
+まず、find と md5 のバイナリファイルをリモートマシンに
+.Xr scp 1
+してから、
+リモートシステムのすべてのファイル
+.Pq もしくは、少なくとも /, /var, /usr パーティション!
+に対して md5 を適用するシェルコマンドを
+ssh を使ってリモートマシンで実行するものです。
+安全なマシンは、チェック結果をファイルにコピーし、前回のチェック結果と
+diff を取り
+.Pq または、安全なマシン自身のバイナリと比較する
+違いを
+毎日のレポートとしてスタッフメンバひとりひとりにメールを送ります。
+.Pp
+この種のチェックを行なうもう一つの方法として、安全なマシンに対して、
+他のマシンの主なファイルシステムを NFS export する方法があります。
+このやり方はいくらかネットワークに負荷を掛けることになりますが、
+侵入者がチェックを探知したり偽造したりすることは、
+事実上不可能になります。
+.Pp
+優れたセキュリティスクリプトは、一般ユーザやスタッフメンバのアクセス制御
+ファイル: .rhosts, .shosts, .ssh/authorized_keys など、MD5 での精細な
+チェックから洩れそうなファイルの変更をチェックします。
+.Pp
+優れたセキュリティスクリプトは、すべてのファイルシステム上で suid/sgid
+バイナリに対してチェックを行ない、前回のチェック結果もしくは何らかの
+基準
+.Pq "例えば、基準を週 1 回にする"
+からの差分だけでなく、
+それらの存在そのものを報告するものです。
+.Sq nosuid
+オプションを
+fstab/mount で指定することで、あるファイルシステム上の suid/sgid
+バイナリの実行機能をオフにすることができますが、root によるこれらの
+実行をオフにすることはできません。さらに、root 権限を破った者は誰でも
+自分自身で用意したバイナリをインストールすることだってできます。
+しかしながら、ユーザのディスク空間を大量に持つ場合、
+ユーザパーティションで suid バイナリとデバイス
+.Po
+.Sq nodev
+オプション
+.Pc
+を不許可にしておき、スキャンしないで済ませることも有益かもしれません。
+それでも、私ならば、少なくとも週に 1 回はスキャンする
+でしょう。というのは、タマネギのこの層の目的は侵入の検知だからです。
+.Pp
+プロセスアカウンティング
+.Po
+.Xr accton 1
+参照
+.Pc
+は、侵入後の評価の仕組みとして利用をお勧めする、
+比較的オーバヘッドの低いオペレーティングシステムの機能です。
+侵入を受けた後でも当該ファイルが無傷であるとするなら、
+侵入者が実際のところどのようにしてシステムの root を破ったかを
+追跡するのに際して特に有益です。
+.Pp
+最後に、セキュリティスクリプトはログファイルを処理するようにして、
+ログファイル自体はできるだけ安全性の高い方法で
+(リモート syslog は極めて有益になり得ます)
+生成するようにすべきです。侵入者は自分の侵入の痕跡を覆い隠そう
+としますし、ログファイルはシステム管理者が最初の侵入の時刻と方法を
+追跡してゆくために極めて重要です。
+.Sh 偏執狂的方法
+.Pp
+多少偏執狂的になっても決して悪いことにはなりません。原則的に、
+システム管理者は、便利さに影響を与えない範囲でいくつでもセキュリティ
+機能を追加することができます。また、いくらか考慮した結果、便利さに
+影響を与えるセキュリティ機能を追加することもできます。
+.Sh サービス不能攻撃 (D.O.S attack) についての特記事項
+.Pp
+このセクションではサービス不能攻撃を扱います。サービス不能攻撃は、普通は、
+パケット攻撃です。ネットワークを飽和させる最先端の偽造パケット
+.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.  
-.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.
-.Pp
-Syslogd can be attacked directly and it is strongly recommended that you use
-the -s option whenever possible, and the -a option otherwise.
-.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.
-.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 ).
-.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.
-.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.
+普通に見られるサービス不能攻撃に、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 には、
+.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 は直接攻撃される可能性があるので、可能ならば
+.Fl s
+オプションを用いることを強く推奨します。これができないなら、
+.Fl a
+オプションを使って下さい。
+.Pp
+tcpwrapper の逆 identd などの接続返し
+.Pq connect-back
+を行なうサービスに
+ついては十分注意を払うようにするべきです。これらは直接攻撃を食らう可能性が
+あります。こういう事情があるので、tcpwrapper の逆 ident 機能を使おうとは
+思わないのが一般的なところです。
+.Pp
+境界ルータのところでファイアウォールを設けて、外部からのアクセスに対して
+内部サービスを防御することは実によい考えです。この考え方は、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
+また別のありふれたサービス不能攻撃として、踏み台攻撃
+.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
+偽造パケット攻撃は、カーネルの経路情報キャッシュに過負荷を生じさせるために
+用いられることもあります。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 ,
 .Xr find 1 ,
 .Xr kerberos 1 ,
 .Xr md5 1 ,
 .Xr ssh 1 ,
 .Xr sshd 1 ,
 .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
diff --git a/ja_JP.eucJP/man/man8/pam.8 b/ja_JP.eucJP/man/man8/pam.8
index 985142f72d..2edcce772e 100644
--- a/ja_JP.eucJP/man/man8/pam.8
+++ b/ja_JP.eucJP/man/man8/pam.8
@@ -1,277 +1,282 @@
 .\" 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 名称
 
 PAM \- プラグ可能認証モジュール群
 
 .SH 書式
 .B /etc/pam.conf
 .sp 2
 .SH 解説
 
 本マニュアルの目的は、
 .B PAM
 のクイックイントロダクションです。
 更なる情報は、
 .B "Linux-PAM system administrators' guide"
 を御覧ください。
 
 .sp
 .BR PAM
 は、システム上でアプリケーション (サービス) の認証作業を行う
 ライブラリシステムです。
-本ライブラリが提供する
+本ライブラリは、
 一般的な不変のインタフェース 
-(アプリケーションプログラミングインタフェース - API) は、
+(アプリケーションプログラミングインタフェース - API) を提供します。
 .RB ( login "(1) "
 や
-.BR su "(1)) "
-のような特権許可プログラムの標準の認証作業の実行を遅らせます。
+.BR su "(1) のような) "
+特権許可プログラム
+がこの API に従うことで、
+標準の認証作業を遂行するようになります。
 
 .sp
-PAM アプローチの基本機能は、認証の種類を動的に設定可能とすることです。
+PAM アプローチの基本的な特徴は、認証作業の性質を動的に設定可能とすることです。
 言い換えると、個々のサービス提供アプリケーションがユーザを認証する方法を、
 システム管理者は自由に選択できます。
 この動的設定は、単一の
 .BR PAM
 設定ファイル
 .BR /etc/pam.conf
 の内容で設定されます。
 また、ディレクトリ
 .B /etc/pam.d/
 に個々の設定ファイルを置くことで、設定を行うこともできます。
 .IB "このディレクトリがあると " PAM " は "
 .BI /etc/pam.conf " を無視します。"
 
 .sp
 このマニュアルが対象とするシステム管理者にとっては、
 .BR PAM
 ライブラリの内部動作を理解することは最重要ではありません。
 理解すべき重要なことは、設定ファイルがアプリケーション
 .RB ( サービス )
 と実際に認証作業を行うプラグ可能認証モジュール
 .RB ( PAM )
 との間の接続を
 .I 定義する
 ことです。
 
 .sp
 .BR PAM
 は、
 .I 認証
 作業を次の 4 個の独立した管理グループに分割します:
 .BR "account" " management (アカウント管理); "
 .BR "auth" "entication management (認証管理); "
 .BR "password" " management (パスワード管理); "
 .BR "session" " management (セッション管理)。"
 (設定ファイルでグループを表すために使用する短縮形を目立たさせています。)
 
 .sp
 簡単に言うと、これらのグループは、
-制限されたサービスに対する典型的なユーザ要求の異なった側面の面倒をみています。
+それぞれ、
+ある制限されたサービスに対する典型的なユーザ要求が持つ、異なった側面の
+面倒をみています。
 
 .sp
 .BR account " - "
 アカウント証明型のサービスを提供します。
-「ユーザのパスワードが無効になったか？」
-「このユーザが要求するサービスにアクセスを許されているか？」
+「ユーザのパスワードが期限切れになったか？」
+「このユーザは、要求するサービスにアクセスを許されているか？」
 といった事柄を扱います。
 
 .br
 .BR auth "entication - "
-ユーザが名乗っている人物であることを確定します。
-典型的には、ユーザが満すべき「挑戦 - 応答」の要求で実現されます。
-例えば「あなたが名乗っているその人であるなら、
+ユーザが名乗っている人物本人であることを確定します。
+この確定は、通常は、ユーザが満すべき「挑戦 - 応答」の要求で実現されます。
+例えば「あなたが名乗っているその人本人であるなら、
 あなたのパスワードを入力してください。」が該当します。
 全部の認証がこの型であるわけではなく、
 (スマートカードや生物測定学デバイスなどを使用する)
 ハードウェアベースの認証方法があり、
 適切なモジュールを使用することで、
 より標準的な認証アプローチをシームレスに置き換え可能です -
 これが
 .BR PAM
 の柔軟性です。
 
 .br
 .BR password " - "
 このグループの責任は、認証機構を更新することです。
-典型的には、このようなサービスは
+このようなサービスは
 .BR auth
-グループのサービスと強力な結び付きがあります。
+グループのサービスと強く結び付いているのが普通です。
 認証機構によっては、自己の更新をこの機能に任せているものがあります。
-標準の UN*X のパスワードベースのアクセスは、明かな例です。
+標準の UN*X のパスワードベースのアクセスは、明らかな例です。
 「代わりのパスワードを入力してください。」がこれに該当します。
 
 .br
 .BR session " - "
 このグループの仕事は、サービス提供の前後に実行されるべきことをカバーします。
 このような作業には、認証記録の維持と、
 ユーザのホームディレクトリのマウントが含まれます。
-開始時と終了時にモジュールへのフックを提供することにより、
-ユーザが利用可能なサービスに影響を与えますので、
+開始時と終了時に
+ユーザが利用可能なサービスに影響を与える
+モジュールへのフックを提供するので、
 .BR session
 管理グループは重要です。
 
 .SH 設定ファイル
 
 .BR PAM
 を意識した特権許可アプリケーションは、
 開始時に PAM-API への取り付けを起動します。
 この起動により多くの作業が行われますが、
 最重要事項は設定ファイル
 .BR /etc/pam.conf
 の読み込みです。
 これは、
 .BR /etc/pam.d/
 ディレクトリの内容であることもあります。
 
-これらのファイルは、サービスが要求する認証作業を行う
+これらのファイルは、このサービスが要求する認証作業を行う
 .BR PAM
-と、個々の
+の一覧と、個々の
 .BR PAM
-が失敗したときの PAM-API の適切な動作をリストします。
+が失敗したときの PAM-API の適切な動作の一覧をリストします。
 
 .sp
 .B /etc/pam.conf
 設定ファイルの文法は次の通りです。
 ファイルはルールのリストから構成されます。
-個々のルールは典型的には単一行ですが、
+個々のルールは普通は単一行ですが、
 `\\<LF>' で行末をエスケープすることで複数行に渡ることが可能です。
 コメントは、前に `#' マークを置き、行末まで続きます。
 
 .sp
 各ルールは、空白で区切ったトークンの集合です。
 最初の 3 つは大文字小文字を区別します:
 
 .sp
 .br
 .BR "   service  type  control  module-path  module-arguments"
 
 .sp
 .B /etc/pam.d/
 ディレクトリ中のファイルの文法は、
 .I service 
 フィールドが無い以外は同じです。
 この場合、
 .I service
 は
 .B /etc/pam.d/
 ディレクトリ中のファイルの名前です。
 このファイル名は小文字であることが必要です。
 
 .sp
 .BR PAM
 の重要機能は、
 ある認証作業用に多くの PAM のサービスを組合せる目的で、多くのルールを
 .I 積み重ね可能
 ということです。
 
 .sp
 .BR service
-は、典型的には対応するアプリケーションの親しみのある名前です。
+は、普通は、対応するアプリケーションの親しみのある名前です。
 .BR login
 や
 .BR su
 は良い例です。
-.BR service " の名前 " other
+.BR service " 名 " other
 は
 .I デフォルト
 ルールを与えるために予約されています。
 現在のサービスに関して言及する行のみが
 (そのような行が存在しない場合は
 .BR other
 エントリが)、指定したアプリケーションに関連付けられます。
 
 .sp
 .BR type
-は、ルールが対応する管理グループです。
-後続するモジュールがどの管理グループに関連付けられるべきかを
+は、そのルールに対応する管理グループです。
+後続するモジュールをどの管理グループに関連付けるべきかを
 指定するために使用されます。
 有効なエントリは
 .BR account "; "
 .BR auth "; "
 .BR password "; "
 .BR session
 です。
 これらのトークンの意味は前述してあります。
 
 .sp
 第 3 のフィールド
 .BR control
 は、PAM-API がこの認証作業に失敗したときにどうすべきかを示します。
 有効な
 .BR control
 の値は次の通りです。
 .BR requisite
-- この PAM が失敗すると、認証処理は即時停止します;
+- この PAM が失敗すると、認証処理は即ちに終了します;
 .BR required
 - この PAM が失敗すると、究極的には PAM-API は失敗を返しますが、
 それはこの
 .RB "(" service
 および
 .BR type
-の) 積み重なっているモジュールの残りを起動した後です;
+の) 積み重なっているモジュールの残りが呼び出されたあとです;
 .BR sufficient
 - この種のモジュールが成功すると、
 モジュールの積み重ねの認証条件を満します
 (これより前の
 .BR required
 モジュールが失敗していた場合、このモジュールの成功は
 .I 無視
 されます);
 .BR optional
 - この
 .BR service "+" type
 に関連付けられているモジュールの積み重ねにおける唯一のモジュールである
 場合のみ、このモジュールの成否は意味を持ちます。
 
 .sp
 .BR module-path
 - アプリケーションが使用する PAM の完全なファイル名です。
 
 .sp
 .BR module-arguments
 - 空白で区切られたトークンのリストであり、
 指定した PAM の特定の動作を修正するために使用可能です。
 引数については、個々のモジュールについて記述されているでしょう。
 
 .SH 関連ファイル
 .BR /etc/pam.conf " - 設定ファイル。"
 .br
 .BR /etc/pam.d/ " - "
 .BR PAM
 の設定ディレクトリ。本ディレクトリが存在する場合、
 .B /etc/pam.conf
 ファイルは無視されます。
 .br
 .BR /usr/lib/libpam.so.X " - 動的ライブラリ。"
 .br
 .BR /usr/lib/pam_*.so " - PAM。
 
 .SH エラー
 ライブラリの
 .BR PAM
 システムが発生する典型的なエラーは、
 .BR syslog "(3)"
 に書き込まれます。
 
 .SH 準拠
 DCE-RFC 86.0, October 1995.
 .br
-現在 DCE-RFC 委員会で考察されている追加機能があります。
+現在 DCE-RFC 委員会で検討されている追加機能も含まれています。
 
 .SH バグ
 .sp 2
 知られているものはありません。
 
 .SH 関連項目
 
 .BR "システム管理者用" "、"
 .BR "モジュール開発者用" "、"
 .BR "アプリケーション開発者用
 の、3 つの
 .BR Linux-PAM
 ガイド。
diff --git a/ja_JP.eucJP/man/man8/usbdevs.8 b/ja_JP.eucJP/man/man8/usbdevs.8
index e25e7808da..fd3088ef0b 100644
--- a/ja_JP.eucJP/man/man8/usbdevs.8
+++ b/ja_JP.eucJP/man/man8/usbdevs.8
@@ -1,68 +1,68 @@
 .\" %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.
 .\"
 .\" Author: Lennart Augustsson
 .\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
 .\" 1. Redistributions of source code must retain the above copyright
 .\"    notice, this list of conditions and the following disclaimer.
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
 .\" 3. All advertising materials mentioning features or use of this software
 .\"    must display the following acknowledgement:
 .\"        This product includes software developed by the NetBSD
 .\"        Foundation, Inc. and its contributors.
 .\" 4. Neither the name of The NetBSD Foundation nor the names of its
 .\"    contributors may be used to endorse or promote products derived
 .\"    from this software without specific prior written permission.
 .\"
 .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
 .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 .\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS 
 .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 .\" POSSIBILITY OF SUCH DAMAGE.
 .\"
 .Dd July 12, 1998
 .Dt USBDEVS 8
 .Os
 .Sh 名称
 .Nm usbdevs
 .Nd システムに接続されている USB 機器を表示する
 .Sh 書式
 .Nm
 .Op Fl a Ar addr
 .Op Fl f Ar dev
 .Op Fl v
 .Sh 解説
 .Nm
-は、システムに接続されているすべての USB 機器を、
-それぞれの機器に関する多少の情報と共に表示します。
+は、システムに接続されているすべての USB 機器の一覧を、
+それぞれの機器に関するいくらかの情報とともに表示します。
 各行のインデントは root からの距離を示しています。
 .Pp
 オプションは次の通りです:
 .Bl -tag -width Ds
 .It Fl a Ar addr
 指定されたアドレスにある機器の情報のみを表示します。
 .It Fl f Ar dev
 指定された USB コントローラの情報のみを表示します。
 .It Fl v
 冗長になります。
 .El
 .Sh 関連項目
 .Xr usb 4
 .Sh 歴史
 コマンドは
 .Nx 1.4
 で登場しました。