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