Date: Tue, 10 Oct 2017 13:10:11 +0000 (UTC) From: Ryusuke SUZUKI <ryusuke@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r51098 - head/ja_JP.eucJP/books/handbook/security Message-ID: <201710101310.v9ADAB7p086386@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: ryusuke Date: Tue Oct 10 13:10:10 2017 New Revision: 51098 URL: https://svnweb.freebsd.org/changeset/doc/51098 Log: - Merge the following from the English version: r29000 -> r30930 head/ja_JP.eucJP/books/handbook/security/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/security/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/security/chapter.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/security/chapter.xml Tue Oct 10 09:53:04 2017 (r51097) +++ head/ja_JP.eucJP/books/handbook/security/chapter.xml Tue Oct 10 13:10:10 2017 (r51098) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r29000 + Original revision: r30930 $FreeBSD$ --> <chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="security"> @@ -636,7 +636,7 @@ <sect2> <title>パスワードファイルの安全性を高める</title> - <para>できるだけ多くのパスワードを <literal>*</literal> で外し、 + <para>できるだけ多くのパスワードをアスタリスクで外し、 それらのアカウントのアクセスには ssh や Kerberos を使うようにすることが、唯一の確実な方法です。 暗号化パスワードファイル @@ -717,10 +717,10 @@ のタマネギの最後の層はおそらく最も重要なもの — 検出で す。セキュリティの残りのものは、突然の侵入を検出できなければ、 まったく有用ではありません (あるいは、もっと悪ければ、安全性に - 対する間違った感覚を植え付けてしまいます)。タマネギの仕事の半 - 分は、もう半分の検出側が攻撃者を攻撃の最中に捕えるようにするた - めに、攻撃者を食い止めるのではなく侵入を遅らせることなのです。 - </para> + 対する間違った感覚を植え付けてしまいます)。 + タマネギの仕事の半分は、 + 攻撃者を攻撃の最中に捕えるようにするために、 + 攻撃者を食い止めるのではなく侵入を遅らせることなのです。</para> <para>侵入を検出する最も良い方法は、変更されていたり、消えていた り、入れた覚えがないのに入っているファイルを探すことです。変更 @@ -775,19 +775,19 @@ <para>優れたセキュリティ用スクリプトは、ユーザやスタッフメンバの アクセス設定ファイルの変更もチェックするものです。 <filename>.rhosts</filename>, <filename>.shosts</filename>, - <filename>.ssh/authorized_keys</filename> など … + <filename>.ssh/authorized_keys</filename> など <literal>MD5</literal> チェックの範囲外になってしまうであろう ファイル群です。</para> <para>ユーザ用のディスク容量が非常に大きい場合は、パーティション 上の各ファイルを見て回るのに大変な時間がかかるかもしれません。 - この場合は、マウントフラグを設定して、このパーティションに - suid されたバイナリやデバイスを置けないようにするのが良い考え - です。<literal>nodev</literal> および <literal>nosuid</literal> - オプション (&man.mount.8; 参照) が知るべきものでしょう。 + この場合は、マウントフラグを設定して、 + suid されたバイナリを置けないようにするのが良い考えです。 + <literal>nosuid</literal> オプション + (&man.mount.8; 参照) が知るべきものでしょう。 とにかく少なくとも週に 1 度はファイルシステムをスキャンするべきです。 - なぜなら、この層の目的は、侵入が成功したかどうかに関わらず、侵 - 入があったことの検出をすることだからです。</para> + なぜなら、この層の目的は、侵入が成功したかどうかに関わらず、 + 不正侵入の試みがあったことの検出をすることだからです。</para> <para>プロセスアカウンティング (&man.accton.8; 参照) は、 マシンへの侵入を検出するためのメカニズムとして推奨できる、 @@ -802,8 +802,7 @@ ファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆく ために極めて重要です。ログファイルを永久に残しておくための 1 つの方法は、システムコンソールをシリアルポートにつないで走らせ、 - コンソールを監視している安全なマシンを通して絶えず情報を集める - ことです。</para> + コンソールを監視している安全なマシンに情報を集めることです。</para> </sect2> <sect2> @@ -827,10 +826,11 @@ <para>このセクションではサービス妨害攻撃 (DoS 攻撃) を扱います。 サービス妨害攻撃は、普通は、パケット攻撃です。ネットワークを飽 - 和させる最先端の偽造パケット (spoofed packet) 攻撃に対してシス - テム管理者が打てる手はそれほど多くありませんが、一般的に、その - 種の攻撃によってサーバがダウンしないことを確実にすることで、被 - 害をある限度に食い止めることはできます。</para> + 和させる最先端の偽造パケット (spoofed packet) + 攻撃に対してシステム管理者が打てる手はそれほど多くありませんが、 + 一般的に、以下のような方法により、 + その種の攻撃によってサーバがダウンしないことを確実にすることで、 + 被害をある限度に食い止めることはできます。</para> <orderedlist> <listitem> @@ -843,13 +843,15 @@ </listitem> <listitem> - <para>カーネルの経路情報のキャッシュ。</para> + <para>カーネルの経路情報のキャッシュを過剰に用意する。</para> </listitem> </orderedlist> - <para>よくあるサービス妨害攻撃は、fork するサーバプロセスに対す - るものです。これは、サーバにプロセス、ファイル記述子、メモリを - マシンが死ぬまで食い尽くさせようとするものです。 + <para>よくあるサービス妨害攻撃は、fork + するサーバに対して攻撃するもので、 + 多くの子プロセスを起動させることにより、 + メモリ、ファイル記述子などを使いつくし、 + ホストシステムを最終的に停止させます。 <application>inetd</application> (&man.inetd.8; 参照) には、この種の攻撃を制限するオプションが いくつかあります。マシンがダウンすることを防止することは可能で @@ -867,15 +869,16 @@ <para><application>Sendmail</application> には、 <option>-OMaxDaemonChildren</option> オプションがあります。シ - ステム負荷の値変化には遅れがあるので、sendmail の負荷限界指定 - オプションを使うよりも、このオプションを使う方がまともに動作す - る可能性ははるかに高いです。 + ステム負荷の値変化には遅れがあるので、 + <application>Sendmail</application> + の負荷限界指定オプションを使うよりも、 + このオプションを使う方がまともに動作する可能性ははるかに高いです。 <application>sendmail</application> の実行を開始する際に、 <literal>MaxDaemonChildren</literal> パラメータを設定するべき - です。その値は、通常見込まれる負荷を扱える程度に十分高いが、そ - れだけの数の <application>sendmail</application> を操作しよう - とするとマシンが卒倒してしまうほどには高くないような値に設定す - るべきです。sendmail をキュー処理モード + です。その値は、通常見込まれる負荷を扱える程度に十分高いが、 + それだけの数の <application>Sendmail</application> + インスタンスを操作しようとするとマシンが卒倒してしまうほどには高くないような値に設定するべきです。 + <application>Sendmail</application> をキュー処理モード (<option>-ODeliveryMode=queued</option>) で実行することや、 sendmail デーモン (<command>sendmail -bd</command>) をキュー処 理用プロセス (<command>sendmail -q15m</command>) と別に実行す @@ -883,8 +886,8 @@ 配送を望むのであれば、<option>-q1m</option> のようにすることで、 キュー処理をはるかに短い時間間隔で行うことができます。いずれに しても、<literal>MaxDaemonChildren</literal> オプションに合理 - 的な値を確実に指定して、sendmail がなだれをうって失敗すること - がないようにして下さい。</para> + 的な値を確実に指定して、<application>Sendmail</application> + がなだれをうって失敗することがないようにして下さい。</para> <para><application>syslogd</application> は直接攻撃される可能性 があるので、可能ならばいつでも <option>-s</option> オプション @@ -948,7 +951,7 @@ エラー報告の仕掛けを狙うものです。攻撃者は ICMP エラー応答を生 成するパケットを生成し、サーバの受信ネットワークを飽和させ、そ の結果としてサーバが送信ネットワークを ICMP 応答で飽和させてし - まうようにすることができます。mbuf を消費し尽くさせることによ + まうようにすることができます。メモリを消費し尽くさせることによ り、この種の攻撃でサーバをクラッシュさせることも可能です。サー バが生成した ICMP 応答を十分速く送信できない場合、とくにひどい ことになります。 @@ -1015,13 +1018,13 @@ <para>もしあなたが、Kerberos と ssh を使いたいのだとしたら、 両者に関して言っておかねばならない問題がいくつかあります。 - Kerberos V は大変優れた認証プロトコルですが、Kerberos 化された + Kerberos 5 は大変優れた認証プロトコルですが、Kerberos 化された <application>telnet</application> や <application>rlogin</application> は、バイナリストリームを扱う のに不向きになってしまうようなバグがあります。さらに、デフォル トでは、Kerberos は <option>-x</option> オプションを使わない限 りセッションを暗号化してくれません。 - <application>ssh</application> では、デフォルトですべてを暗号 + <application>Ssh</application> では、デフォルトですべてを暗号 化してくれます。</para> <para>ssh はあらゆる場面でとても良く働いてくれます。 @@ -1039,7 +1042,7 @@ <para>スタッフのログインには、Kerberos を組み合せた ssh を使用することを勧めます。 - <application>ssh</application> は、Kerberos 対応機能と一緒 + <application>Ssh</application> は、Kerberos 対応機能と一緒 にコンパイルできます。こうすると、見えてしまうかもしれない ssh 鍵をあまりあてにしないで良いようになります。 また、それと同時に、Kerberos 経由でパスワードを保護することもできます。 @@ -1054,7 +1057,7 @@ </sect1> <sect1 xml:id="crypt"> - <info><title>DES, MD5 と Crypt</title> + <info><title>DES, Blowfish, MD5 と Crypt</title> <authorgroup> <author><personname><firstname>Bill</firstname><surname>Swingle</surname></personname><contrib>改訂: </contrib></author> </authorgroup> @@ -1068,6 +1071,7 @@ </indexterm> <indexterm><primary>crypt</primary></indexterm> + <indexterm><primary>Blowfish</primary></indexterm> <indexterm><primary>DES</primary></indexterm> <indexterm><primary>MD5</primary></indexterm> @@ -4571,17 +4575,16 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@h </screen> <para>&man.ssh-keygen.1; は認証に使う為の公開鍵と秘密鍵のペアを作ります。 - DSA または RSA 鍵に応じて、 + <acronym>DSA</acronym> または <acronym>RSA</acronym> 鍵に応じて、 秘密鍵は <filename>~/.ssh/id_dsa</filename> または <filename>~/.ssh/id_rsa</filename> に保存され、 公開鍵は <filename>~/.ssh/id_dsa.pub</filename> または <filename>~/.ssh/id_rsa.pub</filename> にそれぞれ保存されます。 公開鍵はセットアップのために、 + <acronym>DSA</acronym> または <acronym>RSA</acronym> + のどちらを使う場合にも、 リモートマシンの <filename>~/.ssh/authorized_keys</filename> - にも置かなければなりません。RSA バージョン 1 - の公開鍵も同様にリモートマシンの - <filename>~/.ssh/authorized_keys</filename> - 内に置かれなければなりません。</para> + ファイルに含まれてなければなりません。</para> <para>これでパスワードの代わり SSH 鍵を使ってリモートマシンに接続できるようになったはずです。</para> @@ -4874,7 +4877,7 @@ user@unfirewalled-system.example.org's password: <user <para>スナップショットのようなファイルシステムの拡張と連携して、 FreeBSD 5.0 以降ではファイルシステムアクセス制御リスト - (<acronym>ACLs</acronym>) によるセキュリティを提供しています。</para> + (<acronym>ACL</acronym>) によるセキュリティを提供しています。</para> <para>アクセス制御リストは、標準的な &unix; のパーミッションモデルを、 非常に互換性の高い (&posix;.1e) やり方で拡張しています。 @@ -4887,10 +4890,10 @@ user@unfirewalled-system.example.org's password: <user <programlisting>options UFS_ACL</programlisting> - <para>もしこのオプションが組み込まれていなければ、<acronym>ACLs</acronym> + <para>もしこのオプションが組み込まれていなければ、<acronym>ACL</acronym> に対応したファイルシステムをマウントしようとすると、 警告が表示されます。このオプションは <filename>GENERIC</filename> - カーネルに含まれています。<acronym>ACLs</acronym> + カーネルに含まれています。<acronym>ACL</acronym> は、ファイルシステムの拡張属性が有効になっていることに依存しています。 拡張属性は、次世代 &unix; ファイルシステムである <acronym>UFS2</acronym> でネイティブ対応されています。</para> @@ -4904,22 +4907,22 @@ user@unfirewalled-system.example.org's password: <user <acronym>UFS1</acronym> よりも <acronym>UFS2</acronym> の方がおすすめです。</para></note> - <para><acronym>ACLs</acronym> は、マウント時の管理フラグ + <para><acronym>ACL</acronym> は、マウント時の管理フラグ <option>acls</option> で有効にされます。 これは <filename>/etc/fstab</filename> に記述できます。 マウント時のフラグは、&man.tunefs.8; を使って、ファイルシステムヘッダのスーパブロックにある - <acronym>ACLs</acronym> フラグを変更するという方法で、 + <acronym>ACL</acronym> フラグを変更するという方法で、 常に自動で設定されるようになります。一般的には、 下記の理由からスーパブロックフラグを使う方がよいでしょう。</para> <itemizedlist> <listitem> - <para>マウント時に指定した <acronym>ACLs</acronym> フラグは再マウント + <para>マウント時に指定した <acronym>ACL</acronym> フラグは再マウント (&man.mount.8; <option>-u</option>) 時に変更できません。完全に &man.umount.8; した上で、新たに &man.mount.8; するしかありません。これは、起動後にルートファイルシステムで - <acronym>ACLs</acronym> を有効にできないことを意味します。 + <acronym>ACL</acronym> を有効にできないことを意味します。 また、ファイルシステムを利用し始めた後では、 その配列を変えられないことも意味しています。</para> </listitem> @@ -4927,31 +4930,31 @@ user@unfirewalled-system.example.org's password: <user <listitem> <para>スーパブロックフラグを設定すると、<filename>fstab</filename> に記述されていなかったり、デバイスの順番が変わってしまっても、常に - <acronym>ACLs</acronym> が有効な状態でマウントされます。 - こうすることで、ファイルシステムを <acronym>ACLs</acronym> - を有効にしないままマウントしてしまい、<acronym>ACLs</acronym> + <acronym>ACL</acronym> が有効な状態でマウントされます。 + こうすることで、ファイルシステムを <acronym>ACL</acronym> + を有効にしないままマウントしてしまい、<acronym>ACL</acronym> が正しくないかたちで強制され、 セキュリティ問題につながることを防ぎます。</para> </listitem> </itemizedlist> - <note><para><acronym>ACLs</acronym> の動作を変更して、まったく新たに + <note><para><acronym>ACL</acronym> の動作を変更して、まったく新たに &man.mount.8; を行わなくてもフラグを有効にできるようにすることも可能でしょう。 - しかし、我々は、うっかり <acronym>ACLs</acronym> + しかし、我々は、うっかり <acronym>ACL</acronym> を有効にしないでマウントしてしまうのを防ぐようにした方が望ましいと考えました。 - <acronym>ACLs</acronym> を有効にし、その後無効にしてから、 + <acronym>ACL</acronym> を有効にし、その後無効にしてから、 拡張属性を取り消さないでまた有効にしてしまうと、 鬱陶しい状態に自分で入り込んでしまえるからです。 - 一般的には、一度ファイルシステムで <acronym>ACLs</acronym> + 一般的には、一度ファイルシステムで <acronym>ACL</acronym> を有効にしたら、無効にすべきではありません。そうしてしまうと、 ファイル保護がシステムのユーザの意図と齟齬をきたす可能性があるばかりか、 - <acronym>ACLs</acronym> を再度有効にすると、 + <acronym>ACL</acronym> を再度有効にすると、 それまでパーミッションが変更されてきたファイルに古い - <acronym>ACLs</acronym> を割り当ててしまい、 + <acronym>ACL</acronym> を割り当ててしまい、 予想しない動作につながることも考えられます。</para></note> - <para><acronym>ACLs</acronym> を有効にしたファイルシステムは、 + <para><acronym>ACL</acronym> を有効にしたファイルシステムは、 パーミッション設定の表示に <literal>+</literal> (プラス) 記号がつきます。例えば、次のようになります。</para> @@ -4963,7 +4966,7 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_ <para>ここでは、ディレクトリ <filename>directory1</filename>, <filename>directory2</filename> および <filename>directory3</filename> - のすべてで <acronym>ACLs</acronym> が働いています。 + のすべてで <acronym>ACL</acronym> が働いています。 ディレクトリ <filename>public_html</filename> は対象外です。</para> <sect2> @@ -5047,7 +5050,7 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_ と呼ばれる追加のユーティリティが、 この目的のために用意されています。</para> - <para><filename role="package">security/portaudit</filename> port は、 + <para><filename role="package">ports-mgmt/portaudit</filename> port は、 &os; セキュリティチームおよび ports 開発者がアップデートし、管理している、 既知のセキュリティ問題に対するデータベースを入手します。</para> @@ -5055,7 +5058,7 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_ <para><application>Portaudit</application> を使うには、 Ports Collection からインストールしてください。</para> - <screen>&prompt.root; <userinput>cd /usr/ports/security/portaudit && make install clean</userinput></screen> + <screen>&prompt.root; <userinput>cd /usr/ports/ports-mgmt/portaudit && make install clean</userinput></screen> <para>インストールの過程で、 &man.periodic.8; の設定ファイルはアップデートされ、
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201710101310.v9ADAB7p086386>