Refine translation.

Submitted by:	Hiroo Ono <hiroo _at_ jp dot FreeBSD dot org>
Reference:	[doc-jp-work 1737]

ja_JP.eucJP/books/handbook/security/chapter.sgml

@@ -658,29 +658,29 @@
 	<devicename>/dev/kmem</devicename>
 	という悩みの種がまだ残っています。この問題に関しては、侵入者は
 	raw ディスクデバイスに書き込
-	むこともできます。また、モジュールローダ、&man.kldload.8; とい
+	むこともできます。ほかにも、モジュールローダ、&man.kldload.8; とい
 	う、別のカーネル機能があります。やる気まんまんの侵入者は、KLD
 	モジュールを使って自分独自の <devicename>bpf</devicename>
 	もしくはその他覗き見デバイス
-	を動作中のカーネルにインストールすることができます。この問題を
+	を動作中のカーネルにインストールできます。この問題を
 	避けるため、システム管理者はカーネルをより高い安全レベル (
 	securelevel)、少なくとも安全レベル 1 で実行させる必要がありま
-	す。<command>sysctl</command> を使って
+	す。安全レベルは <command>sysctl</command> を使って
 	<varname>kern.securelevel</varname>
-	変数に安全レベルを設定する
-	ことができます。ひとたび安全レベルに 1 を設定すると、raw デバ
+	変数を操作して設定できます。ひとたび安全レベルに 1 を設定すると、raw デバ
 	イスに対する書き込みアクセスは拒否され、たとえば
 	<literal>schg</literal> のような特別な
 	<command>chflags</command> フラグの機能が
 	強制されます。システム起動に関わる重要なバイナリやディレクトリ、
 	スクリプトファイルなど、安全レベルが設定されるまでの間に実行さ
-	れるすべてのものに対しても <literal>schg</literal> フラグを on
-	にしておくことも確実に実行してください。この設定をやり過ぎても
+	れるすべてのものに対しても、確実に <literal>schg</literal>
+	フラグを設定してください。この設定をやり過ぎても
 	構いませんが、より高い安全レベルで動作している場合、システムの
 	アップグレードがはるかに困難になります。システムをより高い安全
 	レベルで実行させるようにするが、すべてのシステムファイルとディ
-	レクトリに <literal>schg</literal> フラグを設定しないという妥
-	協をする方法もあります。もう一つの可能性としては、単純に
+	レクトリに <literal>schg</literal>
+	フラグを設定しないというところで妥協するという手もあります。
+	もう一つの可能性としては、単純に
 	<filename>/</filename> および <filename>/usr</filename> を読み
 	込み専用でマウントすることです。ここで特筆すべきことは、システ
 	ムを守ろうとして厳しくしすぎると、侵入を検出するという非常に重
@@ -715,8 +715,7 @@
 	クリプトを書けば、
 	スクリプトは潜在的な攻撃者からはほぼ見えなくなります。
 	これは重要なことです。この有効性を最大限に活用
-	するためには、一般的に、アクセスの制限されたマシンから実際に使っ
-	ている他のマシンへのかなりのアクセスを許す必要があります。普
+	するためには、一般的に、アクセスの制限されたマシンから実際に使っている他のマシンへのかなりのアクセスを許可する必要があります。普
 	通は、他のマシンからアクセス制限されたマシンへ読み込み専用の
 	NFS エクスポートをしたり、アクセス制限されたマシンから他のマシンへ
 	ssh 接続を行なうために、
@@ -726,10 +725,9 @@
 	事実上検出されずに監視できるようになります。アクセス制限された
 	サーバがスイッチを通してクライアントに接続されている場合、たい
 	てい NFS がより良い選択肢です。アクセス制限されたサーバがハブ
-	を通したり、いくつかのルーティング層を通したりしてクライアント
-	に接続する場合、
-	NFS は (ネットワークの面で) あまりにも危険な方法かもしれず、
-	ssh の方が認証を行った跡は残りますが、より良い方法でしょう。</para>
+	や、いくつかのルーティング層を通してクライアントに接続している場合、
+	NFS は (ネットワークの面で) あまりにも危険なので、
+	ssh の方が認証を行った跡は残りますが、良い方法でしょう。</para>
 
       <para>アクセス制限されたマシンに、監視しようとするクライアントシ
 	ステムへの少なくとも読み込みのアクセス権を与えたら、次に実際に
@@ -745,7 +743,7 @@
 	れたセキュリティ用スクリプトは、<filename>/</filename> および
 	<filename>/usr</filename> などのシステムパーティション上で不適
 	当に suid されたバイナリや、新たに作成されたファイルや削除され
-	たファイルもチェックするでしょう。</para>
+	たファイルがないかどうかを調べるでしょう。</para>
 
       <para>NFS ではなく、ssh を使用する場合は、
 	セキュリティ用スクリプトを書くのはずっと難しいことで
@@ -2838,7 +2836,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
 
       <note>
 	<para><command>accept</command>
-	  コマンドのログ取りをおこなっていると、
+	  コマンドでログを取っていると、
 	  ファイアウォールをパケットが一つ通過する毎に 1
 	  行のログが生成されるため <emphasis>大量の</emphasis>
 	  ログデータが発生します。そのため、大規模な FTP/HTTP
@@ -2848,8 +2846,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
 	  を増加させてしまいます。<application>syslogd</application>
 	  もログをディスクに記録するなど、より多くの CPU タイムを
 	  使用し始め、実に容易に <filename>/var/log</filename>
-	  が置かれているパーティションを
-	  パンクさせてしまう可能性があります。</para>
+	  が置かれているパーティションを溢れさせてしまう可能性があります。</para>
       </note>
 
       <para>ファイアウォールは、
@@ -2941,7 +2938,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
 	</emphasis> にすぎません。
 	ファイアウォールでどのようなフィルタルールを使用するかは、
 	あなた自身が 決めなければなりません。
-	これまでのアドバイスにしたがったにも関わらず、
+	これまでのアドバイスに従ったにも関わらず、
 	誰かがあなたのネットワークに 侵入してきたとしても、
 	わたしたちは「いかなる」責任もとることはできません。</para>
     </sect2>