diff --git a/ja_JP.eucJP/books/handbook/security/chapter.xml b/ja_JP.eucJP/books/handbook/security/chapter.xml index f2a2db62e2..b433fa2d29 100644 --- a/ja_JP.eucJP/books/handbook/security/chapter.xml +++ b/ja_JP.eucJP/books/handbook/security/chapter.xml @@ -3,28 +3,37 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r38230 + Original revision: r38269 $FreeBSD$ --> - セキュリティ + + + セキュリティ + - MatthewDillon本章の基にした security(7) マニュアルページの執筆: + + + Matthew + Dillon + + + 本章の基にした security(7) マニュアルページの執筆: + - セキュリティ - 訳: &a.jp.hino;、(jpman プロジェクトの成果を利用させ - ていただきました)。 + 訳: &a.jp.hino;、(jpman + プロジェクトの成果を利用させていただきました)。 この章では この章では、基本的なシステムセキュリティの考え方、 覚えておくべき一般的なルールを紹介し、 - &os; における高度な話題について簡単に説明します + &os; における高度な話題について簡単に説明します。 ここで扱う話題の多くは、 一般的なシステムやインターネットセキュリティにもあてはまります。 インターネットはもはや、誰もが親切な隣人であろうとする @@ -105,8 +114,8 @@ + linkend="mac"> and Internet Firewalls are discussed in . --> @@ -115,8 +124,8 @@ セキュリティとは、システム管理者をいつも悩ませる仕事の一つです。 すべての BSD &unix; マルチユーザシステムは、 従来からいくつかのセキュリティ機構を備えていますが、 - ユーザを疑心暗鬼に陥らせないように追加のセキュリティ機構を構築し - 保守する仕事はおそらく、システム管理者としてもっとも大きな責務の一つでしょう。 + ユーザを疑心暗鬼に陥らせないように追加のセキュリティ機構を構築し保守する仕事はおそらく、 + システム管理者としてもっとも大きな責務の一つでしょう。 マシンの安全性に反映されるのは、管理者が作業したことだけです。 またセキュリティ問題は、快適な環境に必要なものと競合します。 一般に &unix; システムは膨大な数のプロセスを同時に動作させることができ、 @@ -159,11 +168,13 @@ DoS 攻撃 サービス妨害 (DoS) + セキュリティ DoS 攻撃 サービス妨害 (DoS) + サービス妨害 (DoS) サービス妨害攻撃 (DoS 攻撃) とは、 @@ -176,12 +187,10 @@ パケット一つでマシンをクラッシュさせようとするものもあります。 後者には、カーネルにバグ修正を施すことによってのみ対応することができます。 サーバプロセスに対する攻撃は、オプションを適切に指定することによって、 - 攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで - 対応できる場合が多いです。これらに比べると、 + 攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで対応できる場合が多いです。これらに比べると、 ネットワークへの力任せの攻撃への対応はずっと難しくなります。 たとえば、偽造パケットによる攻撃 (spoof-packet attack) は、 - インターネットからシステムを切り離す以外の方法で - 防ぐことはほとんど不可能です。 + インターネットからシステムを切り離す以外の方法で防ぐことはほとんど不可能です。 この攻撃によって、マシンを落としてしまうことはできないかもしれませんが、 接続しているインターネット回線を飽和させてしまうことはできます。 @@ -195,20 +204,26 @@ このご時勢でも、自分たちのマシンで標準の telnetd, rlogind, - rshd, ftpd - サーバを実行させているシステ - ム管理者は多いのです。これらのサーバは、デフォルトでは、暗号化さ - れたコネクション上で動作していません。その結果、抱えているユーザ - 数が標準くらいであれば、リモートログイン (そのシステムにログイン - するには最も普通で便利な方法です) しているユーザのうち一人以上は、 - パスワードを覗き見られてしまうでしょう。システム管理者が注意深い - 人ならば、たとえログインが成功していたとしても、リモートアクセス - ログを解析して、疑わしい送信元アドレスを探すものです。 + rshd, + ftpd + サーバを実行させているシステム管理者は多いのです。 + これらのサーバは、デフォルトでは、 + 暗号化されたコネクション上で動作していません。 + その結果、抱えているユーザ数が標準くらいであれば、リモートログイン + (そのシステムにログインするには最も普通で便利な方法です) + しているユーザのうち一人以上は、 + パスワードを覗き見られてしまうでしょう。 + システム管理者が注意深い人ならば、 + たとえログインが成功していたとしても、 + リモートアクセスログを解析して、 + 疑わしい送信元アドレスを探すものです。 ひとたび攻撃者がユーザアカウントへのアクセス権を入手したら、 - 攻撃者は root 権限を破れると仮定するべきです。 - しかし、セキュリティを十分維持し、手入れの行き届いたシステムにおい - ては、あるユーザアカウントへのアクセスが可能となっても、 + 攻撃者は root + 権限を破れると仮定するべきです。 + しかし、セキュリティを十分維持し、 + 手入れの行き届いたシステムにおいては、 + あるユーザアカウントへのアクセスが可能となっても、 必ずしも攻撃者に root へのアクセス権を与えるとは限りません。この違いは重要です。 というのは、一般的に @@ -225,7 +240,8 @@ 裏口 (バックドア) - システム管理者は、あるマシン上で root + システム管理者は、あるマシン上で + root 権限を奪取する方法は、 潜在的に何通りもあるということを心しておかねばなりません。 攻撃者は root @@ -233,24 +249,29 @@ 攻撃者が root 権限で実行されているサーバのバグを見つけ、 ネットワーク接続を介して - root 権限を破ることができるかもしれません。 + root + 権限を破ることができるかもしれません。 また、攻撃者は suid-root プログラムに存在するバグを知っていて、 ユーザアカウントを破れば - root 権限を奪取できるかもしれません。 + root + 権限を奪取できるかもしれません。 攻撃者があるマシン上で - root 権限を破る方法を知ったならば、 + root + 権限を破る方法を知ったならば、 攻撃者は裏口を用意する必要がありません。 - これまでに発見され、ふさがれた root + これまでに発見され、ふさがれた + root の穴の多くには、攻撃者が自分のしたことの痕跡を消そうとした作業が、 かなりの割合で含まれています。 そのため、ほとんどの攻撃者は裏口を作るのです。裏口は、 攻撃者がたやすくシステムへの - root アクセスを再び得られるようにしますが、 + root + アクセスを再び得られるようにしますが、 有能な管理者に侵入を検知する便利な手段を与えるものでもあります。 攻撃者に裏口を作らせないようにするということは、 セキュリティにとっては実際には良くないことかもしれません。 - なぜなら、攻撃者が最初に見つけて侵入してきたセキュリティホールは - ふさがれないからです。 + なぜなら、 + 攻撃者が最初に見つけて侵入してきたセキュリティホールはふさがれないからです。 セキュリティを改善する方法は、常に、 タマネギの皮のように階層化する手法 @@ -264,8 +285,9 @@ - root の安全性を高める – - root 権限で動作するサーバと + root + の安全性を高める – root 権限で動作するサーバと suid/sgid バイナリ。 @@ -278,13 +300,13 @@ - カーネルのコア、raw デバイス、ファイルシステムの安全性を - 高める。 + カーネルのコア、raw デバイス、 + ファイルシステムの安全性を高める。 - システムに対して行なわれた、不適切な変更をすばやく検出す - る。 + システムに対して行なわれた、 + 不適切な変更をすばやく検出する。 @@ -292,12 +314,13 @@ - 本章の次の節では、上記の各項目についてより深く掘り下げていき - ます。 + 本章の次の節では、 + 上記の各項目についてより深く掘り下げていきます。 &os; の安全性を高める + セキュリティ &os; の安全性を高める @@ -305,6 +328,7 @@ コマンド対プロトコル + この文書を通して、アプリケーションを指すのには 太字 を使い、 コマンドを指す場合には、等幅 フォントを使います。 @@ -314,91 +338,98 @@ ssh などに対して有効です。 - - セキュリティ - 安全性を高める - - - 以下の節では、本章の前節 - でとりあげた &os; システムの安全性を高める方法について - 述べます。 + 以下の節では、本章の 前節 でとりあげた &os; + システムの安全性を高める方法について述べます。 <systemitem class="username">root</systemitem> アカウントとスタッフアカウントの安全性を高める + su root - のアカウントの安全性を確保しないうちから - スタッフのアカウントの安全性をうんぬんしてもしかたがありません。 + のアカウントの安全性を確保しないうちからスタッフのアカウントの安全性をうんぬんしてもしかたがありません。 ほとんどのシステムでは、root - アカウントに割り当てたパスワードが 1 つあり - ます。まず最初にすべきことは、このパスワードはいつで - も不正利用の危険に晒されていると仮定することです。これは - root + アカウントに割り当てたパスワードが 1 + つあります。まず最初にすべきことは、 + このパスワードはいつでも不正利用の危険に晒されていると仮定することです。 + これは root のパスワードを消すべきだと言っているのではありません。 root のパスワードは、マシンにコンソールからアクセスするのには、 - ほとんどいつでも必要なものです。ここで言いたいのは、コンソール - 以外からは、そして可能なら &man.su.1; コマンドを実行する場合も + ほとんどいつでも必要なものです。 + ここで言いたいのは、コンソール以外からは、 + そして可能なら &man.su.1; コマンドを実行する場合も root - のパスワードを使えないようにするべきである、ということで - す。たとえば、あなたが使っている pty が、 - /etc/ttys ファイルで insecure と指定 - されているか確認してください。そうすると、 + のパスワードを使えないようにするべきである、ということです。 + たとえば、あなたが使っている pty が、 + /etc/ttys ファイルで insecure + と指定されているか確認してください。そうすると、 telnet や rlogin 経由では - root で直接ログインできないようになります。 + root + で直接ログインできないようになります。 これは、/etc/ssh/sshd_config を編集して PermitRootLogin に no が設定されるようにすることで実現できます。 - sshd のような、別のログインサービス - を使っている場合でも同様に、直接 root - へログインすることを許し - ていないかどうか確認してください。すべてのアクセス手段 — - たとえば FTP + sshd のような、 + 別のログインサービスを使っている場合でも同様に、直接 + root + へログインすることを許していないかどうか確認してください。 + すべてのアクセス手段 — たとえば FTP のようなサービスが、良くクラックの対象となることを考えましょう。 root への直接ログインは、 システムコンソール経由でのみ可能であるべきなのです。 + wheel - また当然、システム管理者として自分が root - になれるようにしておく必要が - ありますから、そのための穴をいくつか開けておきます。し - かし、それらの穴を動作させるには、さらに追加のパスワード認証が - 必要であるようにしておくことが重要です。 - root でアクセス可能と - する方法の一つとして、適切なスタッフアカウントを + また当然、システム管理者として自分が + root + になれるようにしておく必要がありますから、 + そのための穴をいくつか開けておきます。 + しかし、それらの穴を動作させるには、 + さらに追加のパスワード認証が必要であるようにしておくことが重要です。 + root + でアクセス可能とする方法の一つとして、適切なスタッフアカウントを (/etc/group 中の) - wheel グループに加えることがあります。 - wheel グループに入っているスタッフメンバは + wheel + グループに加えることがあります。 + wheel + グループに入っているスタッフメンバは su を使って root になることが許されます。 パスワードエントリにおいて、スタッフメンバを - wheel グループに置くことによって直接 + wheel + グループに置くことによって直接 wheel 権限を与えてはいけません。スタッフメンバのアカウントは - staff グループに所属させるべきで、その上で + staff + グループに所属させるべきで、その上で /etc/group ファイルを通して - wheel グループに加えるべきです。実際に - root アクセスの必要なスタッフメンバのみ - wheel グループに置くようにすべきです。 + wheel + グループに加えるべきです。実際に + root + アクセスの必要なスタッフメンバのみ + wheel + グループに置くようにすべきです。 他の認証方法の場合、たとえば Kerberos を使用する場合には、 root アカウントの Kerberos .k5login ファイルを使えば、誰も wheel グループに置く必要なく root に &man.ksu.1; - することを許可できます。このやり - 方はよりよい解決策なのかもしれません。なぜなら、 - wheel のメカニズムでは、侵入者がパスワード - ファイルを手に入れ、スタッフアカウントのいずれか 1 つを破るこ - とができると、 - root を破ることがまだできてしまうからです。 - wheel のメカニズムを用いる方が、 - 何もしないよりは良いのですが、 + することを許可できます。 + このやり方はよりよい解決策なのかもしれません。なぜなら、 + wheel のメカニズムでは、 + 侵入者がパスワードファイルを手に入れ、スタッフアカウントのいずれか + 1 つを破ることができると、 + root + を破ることがまだできてしまうからです。 + wheel + のメカニズムを用いる方が、何もしないよりは良いのですが、 必ずしも最も安全な選択肢とは限りません。 アカウントを完全にロックするには、 @@ -430,40 +461,42 @@ ユーザが &man.ssh.1; の鍵を設定するなどといった認証手段を利用しなければなりません。 - これらのセキュリティの仕組みでは、制限の強いサーバから - 制限の弱いサーバへログインすることを前提としています。たとえば、 - メインマシンで、様々な種類のサーバを実行させている場合、ワーク - ステーションではそれらのサーバを実行させてはなりません。ワーク - ステーションを十分に安全にしておくためには、実行するサーバの数 - を、一つもサーバが実行されていないというくらいにまでできる限り - 減らすべきです。また、パスワードで保護されたスクリーンセーバを - 走らせておくべきです。ワークステーションへの物理的アクセスが与 - えられたとすると、もちろん言うまでもなく、攻撃者は管理者が設定 - したいかなる種類のセキュリティをもうち破ることができるのです。 + これらのセキュリティの仕組みでは、 + 制限の強いサーバから制限の弱いサーバへログインすることを前提としています。 + たとえば、メインマシンで、様々な種類のサーバを実行させている場合、 + ワークステーションではそれらのサーバを実行させてはなりません。 + ワークステーションを十分に安全にしておくためには、 + 実行するサーバの数を、 + 一つもサーバが実行されていないというくらいにまでできる限り減らすべきです。 + また、パスワードで保護されたスクリーンセーバを走らせておくべきです。 + ワークステーションへの物理的アクセスが与えられたとすると、 + もちろん言うまでもなく、 + 攻撃者は管理者が設定したいかなる種類のセキュリティをもうち破ることができるのです。 このことは、管理者として必ず考えておかねばならない問題ですが、 - システム破りの大多数は、ネットワーク経由でリモートから、ワーク - ステーションやサーバへの物理的アクセス手段を持たない人々によっ - て行われるという事実もまた、念頭に置いておく必要があります。 - + システム破りの大多数は、ネットワーク経由でリモートから、 + ワークステーションやサーバへの物理的アクセス手段を持たない人々によって行われるという事実もまた、 + 念頭に置いておく必要があります。 Kerberos のような方法を使うことで、 - スタッフアカウントのパ - スワードの変更もしくは停止を一箇所で行なうことと、スタッフメン - バがアカウントを持つすべてのマシンに即時にその効果を及ぼすこと - が可能となります。スタッフメンバのアカウントが危険に晒されたと - きに、すべてのマシンでスタッフメンバのパスワードを即座に変更す - る能力を過小評価してはいけません。パスワードが分散されている状 - 況では、N 台のマシンでパスワードを変更すると、てんやわんやの事 - 態を招く可能性があります。Kerberos を使用すると、パスワードの - 再発行に制限 (re-passwording restriction) を課することもできま - す。この機能を使うことにより、ある Kerberos チケットをしばらく - 経つとタイムアウトにすることができるだけでなく、一定期間 ( 例 - えば、1 ヶ月に 1 回) 経つと、ユーザに新しいパスワードを選ぶよ - うに要求することもできます。 + スタッフアカウントのパスワードの変更もしくは停止を一箇所で行なうことと、 + スタッフメンバがアカウントを持つすべてのマシンに即時にその効果を及ぼすことが可能となります。 + スタッフメンバのアカウントが危険に晒されたときに、 + すべてのマシンでスタッフメンバのパスワードを即座に変更する能力を過小評価してはいけません。 + パスワードが分散されている状況では、 + N 台のマシンでパスワードを変更すると、 + てんやわんやの事態を招く可能性があります。 + Kerberos を使用すると、パスワードの再発行に制限 + (re-passwording restriction) を課することもできます。 + この機能を使うことにより、ある Kerberos + チケットをしばらく経つとタイムアウトにすることができるだけでなく、 + 一定期間 (例えば、1 ヶ月に 1 回) 経つと、 + ユーザに新しいパスワードを選ぶように要求することもできます。 - root 権限で実行されているサーバと SUID/SGID バイナリの安全性を高める + root 権限で実行されているサーバと + SUID/SGID バイナリの安全性を高める + ntalk @@ -489,49 +522,58 @@ rlogind - 用心深いシステム管理者は、自分に必要なサーバプロセスだけを - 過不足なく実行させるものです。サードパーティ製のサーバは、よくバグを持っ - ていがちだということに注意して下さい。たとえば、古いバージョンの + 用心深いシステム管理者は、 + 自分に必要なサーバプロセスだけを過不足なく実行させるものです。 + サードパーティ製のサーバは、 + よくバグを持っていがちだということに注意して下さい。 + たとえば、古いバージョンの imapd や popper - を実行させておくのは、全世界に万能の root - の切符を与えているようなものです。自分で注意深くチェックしていない - サーバは、決して実行してはいけません。root + を実行させておくのは、全世界に万能の + root + の切符を与えているようなものです。 + 自分で注意深くチェックしていないサーバは、 + 決して実行してはいけません。 + root で実行させる必要のあるサーバはほとんどありません。たとえば、 ntalk, comsat, - finger デーモンを、専用ユーザの - 砂場 (sandbox) で実行させることができます。 + finger デーモンを、 + 専用ユーザの 砂場 (sandbox) + で実行させることができます。 管理者が膨大な数の問題を経験していないのなら、 - この「砂場」は完 - 璧ではありませんが、セキュリティに関するタマネギ的アプローチは - ここでも成り立ちます。砂場で実行されているサーバプロセスを経由 - して侵入を果たすことができたとしても、攻撃者はさらに砂場から外 - に脱出しなければなりません。攻撃者が通過せねばならない層の数が - 増えれば増えるほど、それだけ攻撃者が侵入に成功する確率が減りま - す。Root の抜け穴は歴史的に、基本システムサーバも含め、 + この「砂場」は完璧ではありませんが、 + セキュリティに関するタマネギ的アプローチはここでも成り立ちます。 + 砂場で実行されているサーバプロセスを経由して侵入を果たすことができたとしても、 + 攻撃者はさらに砂場から外に脱出しなければなりません。 + 攻撃者が通過せねばならない層の数が増えれば増えるほど、 + それだけ攻撃者が侵入に成功する確率が減ります。 + Root の抜け穴は歴史的に、基本システムサーバも含め、 root 権限で実行されるほとんどすべてのサーバプロセスで発見されています。 ユーザが sshd 経由でのみログインし、 telnetd, rshd, - rlogind 経由でログインすることが決 - してないマシンを稼働させているのであれば、それらのサービスを停 - 止させて下さい! + rlogind + 経由でログインすることが決してないマシンを稼働させているのであれば、 + それらのサービスを停止させて下さい! - &os; では、今では ntalkd, + &os; では、今では + ntalkd, comsat, - finger は砂場で実行させることがデフォ - ルトになっています。次に砂場で実行させるべきプログラムの候補と - して、&man.named.8; があります。 + finger + は砂場で実行させることがデフォルトになっています。 + 次に砂場で実行させるべきプログラムの候補として、 + &man.named.8; があります。 /etc/defaults/rc.conf ファイルには、 - named を砂場で実行するために必要な - 引数がコメントアウトされた形式で含まれています。新しいシステム - をインストールしているか、それとも既存のシステムをアップグレー - ドして使っているかに依存しますが、砂場として使用する特別のユー - ザアカウントがインストールされていないかもしれません。用心深い - システム管理者であれば、できるだけいつでも研究を怠らず、サーバ - に砂場を仕込むものでしょう。 + named + を砂場で実行するために必要な引数がコメントアウトされた形式で含まれています。 + 新しいシステムをインストールしているか、 + それとも既存のシステムをアップグレードして使っているかに依存しますが、 + 砂場として使用する特別のユーザアカウントがインストールされていないかもしれません。 + 用心深いシステム管理者であれば、できるだけいつでも研究を怠らず、 + サーバに砂場を仕込むものでしょう。 + sendmail @@ -540,54 +582,60 @@ sendmail, popper, imapd, - ftpd などです。これらのうちいくつか - のサーバには代わりとなるものがありますが、代わりのものをインス - トールするには、あなたが思うより多くの仕事が必要になるかもしれ - ません (便利さという要素がまたも勝利を収めるわけです)。これら - のサーバは、root + ftpd などです。 + これらのうちいくつかのサーバには代わりとなるものがありますが、 + 代わりのものをインストールするには、 + あなたが思うより多くの仕事が必要になるかもしれません + (便利さという要素がまたも勝利を収めるわけです)。 + これらのサーバは、root 権限で実行しなければばならないかもしれません。また、 - これらのサーバ経由で生じる侵入を検出するためには、他の仕組みに - 頼らなくてはならないかもしれません。 + これらのサーバ経由で生じる侵入を検出するためには、 + 他の仕組みに頼らなくてはならないかもしれません。 システムの root - 権限の潜在的な穴で他に大きなものには、シ - ステムにインストールされた suid-root/sgid バイナリがあります。 - これらのバイナリは、rlogin のように、 - /bin, /sbin, /usr/bin または /usr/sbin - に存在するものがほとんどです。100% 安全なものは存在しないとは - いえ、システムデフォルトの siud/sgid バイナリは比較的安全とい - えます。それでもなお、root + 権限の潜在的な穴で他に大きなものには、 + システムにインストールされた suid-root/sgid バイナリがあります。 + これらのバイナリは、 + rlogin のように、/bin, /sbin, /usr/bin または /usr/sbin + に存在するものがほとんどです。 + 100% 安全なものは存在しないとはいえ、 + システムデフォルトの siud/sgid バイナリは比較的安全といえます。 + それでもなお、root セキュリティホールがこれらのバイナリにときおり発見されています。 1998 年に xterm (普通、suid 設定されています) を脆弱にしていた - Xlib の root + Xlib の + root セキュリティホールが見つかりました。 安全である方がよいので、 - 用心深いシステム管理者は残念に思いながらも、スタッフのみが実行 - する必要がある suid バイナリは、スタッフのみがアクセス可能な特 - 別なグループに含めるように制限を加え、誰も使わない suid バイナ - リは (chmod 000 を実行して) 片付けてしまう - でしょう。ディスプレイを持たないサーバは、一般的に + 用心深いシステム管理者は残念に思いながらも、 + スタッフのみが実行する必要がある suid バイナリは、 + スタッフのみがアクセス可能な特別なグループに含めるように制限を加え、 + 誰も使わない suid バイナリは + (chmod 000 を実行して) 片付けてしまうでしょう。 + ディスプレイを持たないサーバは、一般的に xterm のバイナリを必要としません。 - sgid バイナリもほとんど同様の危険な存在になり得ます。侵入者が - kmem に sgid されたバイナリを破ることができた場合、その侵入者 - は /dev/kmem を読み出すことができるように - なるでしょう。つまり、暗号化されたパスワードファイルを読み出す - ことができるようになるので、パスワードを持つどのアカウントをも、 + sgid バイナリもほとんど同様の危険な存在になり得ます。 + 侵入者が kmem に sgid されたバイナリを破ることができた場合、 + その侵入者は /dev/kmem + を読み出すことができるようになるでしょう。つまり、 + 暗号化されたパスワードファイルを読み出すことができるようになるので、 + パスワードを持つどのアカウントをも、 潜在的な危険に晒すことになります。他にも、 - kmem グループを破った侵入者が pty を通して - 送られたキーストロークを監視できるという危険があります。キース - トロークには、安全な方法でログインするユーザが使っている pty + kmem グループを破った侵入者が pty + を通して送られたキーストロークを監視できるという危険があります。 + キーストロークには、安全な方法でログインするユーザが使っている pty も含まれます。 - tty グループを破った侵入者は、ほぼ任意のユーザの - tty へ書き込みができます。ユーザが端末プログラムやキーボードを - シミュレーションする機能を持ったエミュレータを使っている場合、 - 侵入者は潜在的に、結局そのユーザとして実行されるコマンドをユー - ザの端末にエコーさせるデータストリームを生成できる可能性があり - ます。 + tty + グループを破った侵入者は、ほぼ任意のユーザの + tty へ書き込みができます。 + ユーザが端末プログラムやキーボードをシミュレーションする機能を持ったエミュレータを使っている場合、 + 侵入者は潜在的に、 + 結局そのユーザとして実行されるコマンドをユーザの端末にエコーさせるデータストリームを生成できる可能性があります。 @@ -596,16 +644,14 @@ ユーザアカウントは、普通、安全性を高めることが最も困難です。 スタッフに対しては、とても厳格なアクセス制限を強制しパスワードを アスタリスク で外すことができるでしょうが、 - 管理者が - 持ちうる一般ユーザすべてのアカウントに対して同じことはできない - かもしれません。管理者が十分に統率をとることができるなら、管理 - 者は勝利し、ユーザのアカウントの安全を適切に確保できるかもしれ - ません。それができないならば、よりいっそう気を配って一般ユーザ - のアカウントを監視するよりほかありません。 + 管理者が持ちうる一般ユーザすべてのアカウントに対して同じことはできないかもしれません。 + 管理者が十分に統率をとることができるなら、管理者は勝利し、 + ユーザのアカウントの安全を適切に確保できるかもしれません。 + それができないならば、 + よりいっそう気を配って一般ユーザのアカウントを監視するよりほかありません。 一般ユーザアカウントに対し ssh や Kerberos を利用することには、 - システム管理がさらに増えたりテクニカルサポートが必要に - なるなどの問題があります。それでも、暗号化パスワードファイルと - 比較するとはるかに良い解です。 + システム管理がさらに増えたりテクニカルサポートが必要になるなどの問題があります。 + それでも、暗号化パスワードファイルと比較するとはるかに良い解です。 @@ -615,13 +661,15 @@ それらのアカウントのアクセスには ssh や Kerberos を使うようにすることが、唯一の確実な方法です。 暗号化パスワードファイル - (/etc/spwd.db) は root + (/etc/spwd.db) は + root でのみ読み出し可能だけれども、 たとえ、侵入者が root の書き込み権限は得られなくとも、 読み出しアクセス権限を得ることは可能かもしれません。 セキュリティスクリプトで常にパスワードファイルの変更をチェッ - クし、報告するようにすべきです (ファイルの完全性のチェック + クし、報告するようにすべきです (ファイルの完全性のチェック 節参照)。 @@ -630,30 +678,32 @@ 高める root - の権限を破ると、攻撃者はほとんど何でもできますが、特に重宝さ - れる特定の事柄もいくつかあります。たとえば、最近のカーネルは、組 - み込みのパケット覗き見デバイス (packet sniffing device) ドライ - バを備えているものがほとんどです。&os; では - bpf デバイスと呼ばれています。侵入者 - は普通、侵入済みのマシンでパケット覗き見プログラムを実行させよ - うと試みます。侵入者にわざわざそういう機能を提供する必要はない - ので、ほとんどのシステムで bpf + の権限を破ると、攻撃者はほとんど何でもできますが、 + 特に重宝される特定の事柄もいくつかあります。 + たとえば、最近のカーネルは、組み込みのパケット覗き見デバイス + (packet sniffing device) ドライバを備えているものがほとんどです。 + &os; では bpf デバイスと呼ばれています。 + 侵入者は普通、 + 侵入済みのマシンでパケット覗き見プログラムを実行させようと試みます。 + 侵入者にわざわざそういう機能を提供する必要はないので、 + ほとんどのシステムで bpf デバイスを組み込むべきではありません。 sysctl + bpf デバイスを外しても、 /dev/mem と /dev/kmem という悩みの種がまだ残っています。この問題に関しては、侵入者は raw ディスクデバイスに書き込 - むこともできます。ほかにも、モジュールローダ、&man.kldload.8; とい - う、別のカーネル機能があります。やる気まんまんの侵入者は、KLD + むこともできます。ほかにも、モジュールローダ、&man.kldload.8; + という、別のカーネル機能があります。やる気まんまんの侵入者は、KLD モジュールを使って自分独自の bpf - もしくはその他覗き見デバイス - を動作中のカーネルにインストールできます。この問題を - 避けるため、システム管理者はカーネルをより高いセキュアレベル、 + もしくはその他覗き見デバイスを動作中のカーネルにインストールできます。 + この問題を避けるため、 + システム管理者はカーネルをより高いセキュアレベル、 少なくともセキュアレベル 1 で実行させる必要があります。 カーネルのセキュアレベルはいくつかの方法で設定できます。 @@ -723,93 +773,101 @@ すべてのシステムファイルとディレクトリに schg フラグを設定しないというところで妥協するという手もあります。 もう一つの可能性としては、単純に - / および - /usr + / および /usr を読み込み専用でマウントすることです。 ここで特筆すべきことは、システムを守ろうとして厳しくしすぎると、 侵入を検出するという非常に重要なことができなくなってしまうということです。 - ファイルの完全性のチェック: バイナリ、設定ファイルなど - + ファイルの完全性のチェック: バイナリ、 + 設定ファイルなど - ことこの問題に至ると、システム管理者にできることは、便利さ - という要素がその醜い頭を上げない程度に、コアシステムの設定と制 - 御ファイルを防御することだけです。たとえば、 - / および - /usr - にある大部分のファイルに schg ビットを設定するた - めに chflags を使用するのは、おそらく逆効果 - でしょう。なぜなら、そうすることでファイルは保護できますが、侵 - 入を検出する窓を閉ざしてしまうことにもなるからです。セキュリティ - のタマネギの最後の層はおそらく最も重要なもの — 検出で - す。セキュリティの残りのものは、突然の侵入を検出できなければ、 - まったく有用ではありません (あるいは、もっと悪ければ、安全性に - 対する間違った感覚を植え付けてしまいます)。 + ことこの問題に至ると、システム管理者にできることは、 + 便利さという要素がその醜い頭を上げない程度に、 + コアシステムの設定と制御ファイルを防御することだけです。 + たとえば、/ および /usr + にある大部分のファイルに schg + ビットを設定するために chflags + を使用するのは、おそらく逆効果でしょう。 + なぜなら、そうすることでファイルは保護できますが、 + 侵入を検出する窓を閉ざしてしまうことにもなるからです。 + セキュリティのタマネギの最後の層はおそらく最も重要なもの + — 検出です。 + セキュリティの残りのものは、突然の侵入を検出できなければ、 + まったく有用ではありません + (あるいは、もっと悪ければ、 + 安全性に対する間違った感覚を植え付けてしまいます)。 タマネギの仕事の半分は、 攻撃者を攻撃の最中に捕えるようにするために、 攻撃者を食い止めるのではなく侵入を遅らせることなのです。 - 侵入を検出する最も良い方法は、変更されていたり、消えていた - り、入れた覚えがないのに入っているファイルを探すことです。変更 - されたファイルを探すのに最も良い方法は、もう一つの (しばしば中 - 央に集められた)、アクセスが制限されたシステムから行なうもので - す。さらに安全でアクセス制限されたシステム上でセキュリティ用ス - クリプトを書けば、 + 侵入を検出する最も良い方法は、変更されていたり、 + 消えていたり、入れた覚えがないのに入っているファイルを探すことです。 + 変更されたファイルを探すのに最も良い方法は、もう一つの + (しばしば中央に集められた)、 + アクセスが制限されたシステムから行なうものです。 + さらに安全でアクセス制限されたシステム上でセキュリティ用スクリプトを書けば、 スクリプトは潜在的な攻撃者からはほぼ見えなくなります。 - これは重要なことです。この有効性を最大限に活用 - するためには、一般的に、アクセスの制限されたマシンから実際に使っている他のマシンへのかなりのアクセスを許可する必要があります。普 - 通は、他のマシンからアクセス制限されたマシンへ読み込み専用の + これは重要なことです。 + この有効性を最大限に活用するためには、一般的に、 + アクセスの制限されたマシンから実際に使っている他のマシンへのかなりのアクセスを許可する必要があります。 + 普通は、他のマシンからアクセス制限されたマシンへ読み込み専用の NFS エクスポートをしたり、アクセス制限されたマシンから他のマシンへ ssh 接続を行なうために、 ssh 鍵のペアを作ったりすることで行います。 - ネットワークのトラフィックを別にして、NFS は最も可視性 - のない方法です — 各クライアント上のファイルシステムを、 - 事実上検出されずに監視できるようになります。アクセス制限された - サーバがスイッチを通してクライアントに接続されている場合、たい - てい NFS がより良い選択肢です。アクセス制限されたサーバがハブ - や、いくつかのルーティング層を通してクライアントに接続している場合、 + ネットワークのトラフィックを別にして、 + NFS は最も可視性のない方法です — + 各クライアント上のファイルシステムを、 + 事実上検出されずに監視できるようになります。 + アクセス制限されたサーバがスイッチを通してクライアントに接続されている場合、 + たいてい NFS がより良い選択肢です。 + アクセス制限されたサーバがハブや、 + いくつかのルーティング層を通してクライアントに接続している場合、 NFS は (ネットワークの面で) あまりにも危険なので、 ssh の方が認証を行った跡は残りますが、良い方法でしょう。 - アクセス制限されたマシンに、監視しようとするクライアントシ - ステムへの少なくとも読み込みのアクセス権を与えたら、次に実際に - 監視するためのスクリプトを書かなくてはいけません。NFS マウント - をすれば、&man.find.1; や &man.md5.1; などの単純なシステムユー - ティリティでスクリプトを書くことができます。少なくとも 1 日 1 - 回、クライアントのファイルを直接 md5 にかけ、さらにもっと頻繁 - に /etc および - /usr/local/etc - にあるようなコントロール用 - ファイルを試験するのが一番です。アクセス制限されたマシンが正し - いと知っている、基となる md5 情報と比べて違いが見つかった場合、 - システム管理者に調べて欲しいと悲鳴を上げるようにすべきです。優 - れたセキュリティ用スクリプトは、 - / および - /usr + アクセス制限されたマシンに、 + 監視しようとするクライアントシステムへの少なくとも読み込みのアクセス権を与えたら、 + 次に実際に監視するためのスクリプトを書かなくてはいけません。 + NFS マウントをすれば、&man.find.1; や &man.md5.1; + などの単純なシステムユーティリティでスクリプトを書くことができます。 + 少なくとも 1 日 1 回、クライアントのファイルを直接 md5 にかけ、 + さらにもっと頻繁に /etc および /usr/local/etc + にあるようなコントロール用ファイルを試験するのが一番です。 + アクセス制限されたマシンが正しいと知っている、 + 基となる md5 情報と比べて違いが見つかった場合、 + システム管理者に調べて欲しいと悲鳴を上げるようにすべきです。 + 優れたセキュリティ用スクリプトは、/ および /usr などのシステムパーティション上で不適当に - suid されたバイナリや、新たに作成されたファイルや削除され - たファイルがないかどうかを調べるでしょう。 + suid されたバイナリや、 + 新たに作成されたファイルや削除されたファイルがないかどうかを調べるでしょう。 NFS ではなく、ssh を使用する場合は、 - セキュリティ用スクリプトを書くのはずっと難しいことで - す。スクリプトを動かすためには、クライアントに対してスクリプト - を scp しなくてはいけませんし、それは目に見 - えてしまいます。そして、安全のためには、スクリプトが使うバイナ - リ (find など) を scp する必要もあります。 + セキュリティ用スクリプトを書くのはずっと難しいことです。 + スクリプトを動かすためには、クライアントに対してスクリプトを + scp しなくてはいけませんし、 + それは目に見えてしまいます。 + そして、安全のためには、スクリプトが使うバイナリ (find など) を + scp する必要もあります。 クライアントマシンの ssh クライアントはすでに攻撃されてしまっているかもしれません。 結局のところ、安全でないリンク上の場合は ssh は必要かもしれませんが、ssh を扱うのはとても大変なことです。 - 優れたセキュリティ用スクリプトは、ユーザやスタッフメンバの - アクセス設定ファイルの変更もチェックするものです。 + 優れたセキュリティ用スクリプトは、 + ユーザやスタッフメンバのアクセス設定ファイルの変更もチェックするものです。 .rhosts, .shosts, - .ssh/authorized_keys など - MD5 チェックの範囲外になってしまうであろう - ファイル群です。 + .ssh/authorized_keys など MD5 + チェックの範囲外になってしまうであろうファイル群です。 ユーザ用のディスク容量が非常に大きい場合は、パーティション 上の各ファイルを見て回るのに大変な時間がかかるかもしれません。 @@ -824,41 +882,46 @@ プロセスアカウンティング (&man.accton.8; 参照) は、 マシンへの侵入を検出するためのメカニズムとして推奨できる、 比較的オーバヘッドの少ないオペレーティングシステムの機能です。 - 侵入を受けた後でも当該ファイルが無傷である場合に、侵入者が - 実際にどのようにしてシステムに侵入したかを追跡するのに特に役立ちます。 + 侵入を受けた後でも当該ファイルが無傷である場合に、 + 侵入者が実際にどのようにしてシステムに侵入したかを追跡するのに特に役立ちます。 - 最後に、セキュリティスクリプトはログファイルを処理するよう - にし、ログファイル自体もできるだけ安全性の高い方法で生成するよ - うにすべきです — リモート syslog は極めて有益になり得ま - す。侵入者は自分の侵入の痕跡を覆い隠そうとしますし、また、ログ - ファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆく - ために極めて重要です。ログファイルを永久に残しておくための 1 - つの方法は、システムコンソールをシリアルポートにつないで走らせ、 + 最後に、 + セキュリティスクリプトはログファイルを処理するようにし、 + ログファイル自体もできるだけ安全性の高い方法で生成するようにすべきです + — リモート syslog は極めて有益になり得ます。 + 侵入者は自分の侵入の痕跡を覆い隠そうとしますし、また、 + ログファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆくために極めて重要です。 + ログファイルを永久に残しておくための 1 つの方法は、 + システムコンソールをシリアルポートにつないで走らせ、 コンソールを監視している安全なマシンに情報を集めることです。 偏執狂的方法 - 多少偏執狂的になっても決して悪いことにはなりません。原則的 - に、システム管理者は、便利さに影響を与えない範囲でいくつでもセ - キュリティ機能を追加することができます。 + 多少偏執狂的になっても決して悪いことにはなりません。 + 原則的に、システム管理者は、 + 便利さに影響を与えない範囲でいくつでもセキュリティ機能を追加することができます。 また、いくらか考慮した結果、 便利さに影響を与えるセキュリティ機能を追加することもできます。 より重要なことは、 セキュリティ管理者はこれを多少混ぜこぜにして使うべきだということです。 - — もしあなたが、本文書に書かれている勧告をそのまま使用した場合は、 + — もしあなたが、 + 本文書に書かれている勧告をそのまま使用した場合は、 予想される攻撃者はやはり本文書を読んでいるわけですから、 あなたの防御策を教えてしまうことになります。 サービス妨害攻撃 - サービス妨害 (DoS) + + + サービス妨害 (DoS) + このセクションではサービス妨害攻撃 (DoS 攻撃) を扱います。 - サービス妨害攻撃は、普通は、パケット攻撃です。ネットワークを飽 - 和させる最先端の偽造パケット (spoofed packet) + サービス妨害攻撃は、普通は、パケット攻撃です。 + ネットワークを飽和させる最先端の偽造パケット (spoofed packet) 攻撃に対してシステム管理者が打てる手はそれほど多くありませんが、 一般的に、以下のような方法により、 その種の攻撃によってサーバがダウンしないことを確実にすることで、 @@ -870,8 +933,7 @@ - 踏み台攻撃の制限 (ICMP 応答攻撃、ping broadcast など)。 - + 踏み台攻撃の制限 (ICMP 応答攻撃、ping broadcast など)。 @@ -884,79 +946,84 @@ 多くの子プロセスを起動させることにより、 メモリ、ファイル記述子などを使いつくし、 ホストシステムを最終的に停止させます。 - inetd - (&man.inetd.8; 参照) には、この種の攻撃を制限するオプションが - いくつかあります。マシンがダウンすることを防止することは可能で - すが、この種の攻撃によりサービスが中断することを防止することは - 一般的に言ってできないことに注意する必要があります。 + inetd (&man.inetd.8; 参照) には、 + この種の攻撃を制限するオプションがいくつかあります。 + マシンがダウンすることを防止することは可能ですが、 + この種の攻撃によりサービスが中断することを防止することは一般的に言ってできないことに注意する必要があります。 inetd のマニュアルページを注意深く読んで下さい。特に、 , , オプションに注意して下さい。IP 偽造攻撃 (spoofed-IP attack) は inetd の オプションの裏をかけるので、 - 一般にオプションを組み合わせて使用するべきであることに注意して下さ - い。スタンドアロンサーバの中には、自分自身で fork を制限するパ - ラメータを持っているものがあります。 + 一般にオプションを組み合わせて使用するべきであることに注意して下さい。 + スタンドアロンサーバの中には、自分自身で fork + を制限するパラメータを持っているものがあります。 Sendmail には、 - オプションがあります。シ - ステム負荷の値変化には遅れがあるので、 + オプションがあります。 + システム負荷の値変化には遅れがあるので、 Sendmail の負荷限界指定オプションを使うよりも、 このオプションを使う方がまともに動作する可能性ははるかに高いです。 sendmail の実行を開始する際に、 - MaxDaemonChildren パラメータを設定するべき - です。その値は、通常見込まれる負荷を扱える程度に十分高いが、 + MaxDaemonChildren + パラメータを設定するべきです。 + その値は、通常見込まれる負荷を扱える程度に十分高いが、 それだけの数の Sendmail インスタンスを操作しようとするとマシンが卒倒してしまうほどには高くないような値に設定するべきです。 Sendmail をキュー処理モード () で実行することや、 - sendmail デーモン (sendmail -bd) をキュー処 - 理用プロセス (sendmail -q15m) と別に実行す - ることも、用心深いことと言えます。それでもなおリアルタイムでの - 配送を望むのであれば、 のようにすることで、 - キュー処理をはるかに短い時間間隔で行うことができます。いずれに - しても、MaxDaemonChildren オプションに合理 - 的な値を確実に指定して、Sendmail + sendmail デーモン (sendmail -bd) + をキュー処理用プロセス (sendmail -q15m) + と別に実行することも、用心深いことと言えます。 + それでもなおリアルタイムでの配送を望むのであれば、 + のようにすることで、 + キュー処理をはるかに短い時間間隔で行うことができます。 + いずれにしても、MaxDaemonChildren + オプションに合理的な値を確実に指定して、 + Sendmail がなだれをうって失敗することがないようにして下さい。 - syslogd は直接攻撃される可能性 - があるので、可能ならばいつでも オプション - を用いることを強く推奨します。これができないなら、 + syslogd + は直接攻撃される可能性があるので、可能ならばいつでも + オプションを用いることを強く推奨します。 + これができないなら、 オプションを使って下さい。 - TCP Wrapper の逆 identd などの接 - 続返し (connect-back) を行うサービスについては十分注意を払うよ - うにするべきです。これらは直接攻撃を受ける可能性があります。こ - ういう事情があるので、TCP wrapper の - 逆 ident 機能を使おうとは思わないのが一般的です。 + TCP Wrapper の逆 identd + などの接続返し (connect-back) + を行うサービスについては十分注意を払うようにするべきです。 + これらは直接攻撃を受ける可能性があります。 + こういう事情があるので、TCP wrapper + の逆 ident 機能を使おうとは思わないのが一般的です。 - 境界ルータのところでファイアウォールを設けて、外部からのア - クセスに対して内部サービスを防御するという考えは実によいもので - す。この考えは、LAN の外部からの飽和攻撃を防ぐことにあり、内部 - サービスをネットワークベースの root - 権限への攻撃から防御するこ - とにはあまり考慮を払っていません。ファイアウォールは常に排他的 - に設定して下さい。つまり、ポート A, B, C, D と M から Z - まで以外 のすべてにファイアウォールを設ける + 境界ルータのところでファイアウォールを設けて、 + 外部からのアクセスに対して内部サービスを防御するという考えは実によいものです。 + この考えは、LAN の外部からの飽和攻撃を防ぐことにあり、 + 内部サービスをネットワークベースの root + 権限への攻撃から防御することにはあまり考慮を払っていません。 + ファイアウォールは常に排他的に設定して下さい。 + つまり、ポート A, B, C, D と M から Z まで + 以外 のすべてにファイアウォールを設ける というふうにです。このようにすることで、 named (ゾーンのプライマリである場合)、 ntalkd, - sendmail などのインターネットからア - クセスできるサービスとして特に指定するもの以外の、小さい番号の - ポートすべてをファイアウォールで防御することができます。ファイ - アウォールをこの他のやり方 — つまり包含的もしくは受容的 - なファイアウォールとして設定しようとする場合、 - close することを忘れてしまうサービスがいくつか - 出てきたり、新しい内部サービスを追加したのにファイアウォールの - 更新を忘れたりする可能性がよく出てきます。ファイアウォール上の - 大きい番号のポートを開けておくことにより、小さい番号のポートを - 危険に晒すことなく受容的な動作を許すことができます。&os; で - は、net.inet.ip.portrange への + sendmail + などのインターネットからアクセスできるサービスとして特に指定するもの以外の、 + 小さい番号のポートすべてをファイアウォールで防御することができます。 + ファイアウォールをこの他のやり方 — + つまり包含的もしくは受容的なファイアウォールとして設定しようとする場合、 + close + することを忘れてしまうサービスがいくつか出てきたり、 + 新しい内部サービスを追加したのにファイアウォールの更新を忘れたりする可能性がよく出てきます。 + ファイアウォール上の大きい番号のポートを開けておくことにより、 + 小さい番号のポートを危険に晒すことなく受容的な動作を許すことができます。 + &os; では、net.inet.ip.portrange への sysctl (sysctl -a | fgrep - portrange) をいろいろ使用することで、動的バインドに使用される - ポート番号の範囲を制御できることを記憶にとどめておいてください。 + portrange) をいろいろ使用することで、 + 動的バインドに使用されるポート番号の範囲を制御できることを記憶にとどめておいてください。 これによりファイアウォールの設定を簡略化することもできます。 たとえば、通常の first/last 範囲として 4000 から 5000 を、 高位ポートの範囲として、49152 から 65535 を指定し、 @@ -966,57 +1033,63 @@ また別のよくあるサービス妨害攻撃として、踏み台攻撃 (springboard attack) と呼ばれるものがあります — これは、 - あるサーバを攻撃し、そこ結果として生成される応答が自分自身、ロー - カルネットワーク、そして他のマシンを過負荷に追い込むようにする - 攻撃です。この種の攻撃の中で最もありふれたものに、 - ICMP ping broadcast 攻撃があります。攻撃 - 者は、実際に攻撃したいマシンのアドレスを送信元アドレスに設定し - た ping パケットを偽造して、対象の LAN のブロードキャストアド - レスに向けてパケットを送信します。境界にあるルータがブロードキャ - ストアドレスに対する ping パケットを握り潰すように設定されてい - ない場合、LAN は、詐称された送信元アドレスに向けて応答パケット - を生成するはめになり、犠牲となるマシンが飽和するところまで行っ - てしまいます。攻撃者が同じトリックを異なるネットワーク上のいく - つものブロードキャストアドレスに対して同時に使用した場合、とく - にひどいことになります。これまでに、120 メガビット以上のブロー - ドキャスト攻撃が観測されています。2 番目の踏み台攻撃は、ICMP - エラー報告の仕掛けを狙うものです。攻撃者は ICMP エラー応答を生 - 成するパケットを生成し、サーバの受信ネットワークを飽和させ、そ - の結果としてサーバが送信ネットワークを ICMP 応答で飽和させてし - まうようにすることができます。メモリを消費し尽くさせることによ - り、この種の攻撃でサーバをクラッシュさせることも可能です。サー - バが生成した ICMP 応答を十分速く送信できない場合、とくにひどい - ことになります。 + あるサーバを攻撃し、そこ結果として生成される応答が自分自身、 + ローカルネットワーク、 + そして他のマシンを過負荷に追い込むようにする攻撃です。 + この種の攻撃の中で最もありふれたものに、 + ICMP ping broadcast 攻撃があります。 + 攻撃者は、実際に攻撃したいマシンのアドレスを送信元アドレスに設定した + ping パケットを偽造して、対象の LAN + のブロードキャストアドレスに向けてパケットを送信します。 + 境界にあるルータがブロードキャストアドレスに対する + ping パケットを握り潰すように設定されていない場合、LAN は、 + 詐称された送信元アドレスに向けて応答パケットを生成するはめになり、 + 犠牲となるマシンが飽和するところまで行ってしまいます。 + 攻撃者が同じトリックを異なるネットワーク上のいくつものブロードキャストアドレスに対して同時に使用した場合、 + とくにひどいことになります。これまでに、120 + メガビット以上のブロードキャスト攻撃が観測されています。 + 2 番目の踏み台攻撃は、ICMP エラー報告の仕掛けを狙うものです。 + 攻撃者は ICMP エラー応答を生成するパケットを生成し、 + サーバの受信ネットワークを飽和させ、 + その結果としてサーバが送信ネットワークを ICMP + 応答で飽和させてしまうようにすることができます。 + メモリを消費し尽くさせることにより、 + この種の攻撃でサーバをクラッシュさせることも可能です。 + サーバが生成した ICMP 応答を十分速く送信できない場合、 + とくにひどいことになります。 この種の攻撃の効果を抑制するには、 sysctl 変数の net.inet.icmp.icmplim を使ってください。 踏み台攻撃の 3 つめの主要なクラスに属する攻撃は、 - udp echo サービスのような、特定の - inetd 内部サービスに関連する - ものです。攻撃者は、単に送信元アドレスがサーバ A の echo ポー - トであり、送信先アドレスがサーバ B の echo ポートであるように - UDP パケットを偽造します。ここでサーバ A, B はともにあなたの - LAN に接続されています。この 2 つのサーバは、この一つのパケッ - トを両者の間で互いに相手に対して打ち返しあいます。このようにし - てパケットをほんのいくつか注入するだけで、攻撃者は両方のサーバ - と LAN を過負荷状態にすることができます。同様の問題が内部 - chargen ポートにも存在します。 + udp echo サービスのような、特定の inetd + 内部サービスに関連するものです。 + 攻撃者は、単に送信元アドレスがサーバ A の echo + ポートであり、送信先アドレスがサーバ B の echo + ポートであるように UDP パケットを偽造します。 + ここでサーバ A, B はともにあなたの + LAN に接続されています。この 2 つのサーバは、 + この一つのパケットを両者の間で互いに相手に対して打ち返しあいます。 + このようにしてパケットをほんのいくつか注入するだけで、 + 攻撃者は両方のサーバと LAN を過負荷状態にすることができます。 + 同様の問題が内部 chargen + ポートにも存在します。 有能なシステム管理者はこの手の - inetd 内部テストサービスのすべてを無効にしておくものです。 - + inetd 内部テストサービスのすべてを無効にしておくものです。 - 偽造パケット攻撃は、カーネルの経路情報キャッシュに過負荷を - 生じさせるために用いられることもあります。 + 偽造パケット攻撃は、 + カーネルの経路情報キャッシュに過負荷を生じさせるために用いられることもあります。 net.inet.ip.rtexpire, - rtminexpire, rtmaxcache - の sysctl パラメータを参照して下さい。でた - らめな送信元 IP アドレスを用いた偽造パケット攻撃により、カーネ - ルは、一時的なキャッシュ経路を経路情報テーブルに生成します。こ - れは netstat -rna | fgrep W3 で見ることがで - きます。これらの経路は、普通は 1600 秒程度でタイムアウトになり - ます。カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを - 検知すると、カーネルは動的に rtexpire + rtminexpire, + rtmaxcache + の sysctl パラメータを参照して下さい。 + でたらめな送信元 IP アドレスを用いた偽造パケット攻撃により、 + カーネルは、一時的なキャッシュ経路を経路情報テーブルに生成します。 + これは netstat -rna | fgrep W3 + で見ることができます。 + これらの経路は、普通は 1600 秒程度でタイムアウトになります。 + カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを検知すると、 + カーネルは動的に rtexpire を減らしますが、rtminexpire より小さくなるようには決して減らしません。ここに問題が 2 つあります。 @@ -1033,69 +1106,76 @@ - 自分のサーバが T3 もしくはそれより高速の回線でインターネッ - トに接続されている場合、&man.sysctl.8; を用いて + 自分のサーバが T3 + もしくはそれより高速の回線でインターネットに接続されている場合、 + &man.sysctl.8; を用いて rtexpire と rtminexpire - とを手動で上書きしておくことが思慮深いことといえます。どちらか - 一方でも 0 には決してしないで下さい (自分のマシンをクラッシュ - させたくないのであれば)。両パラメータを 2 秒 - に設定すれば、攻撃から経路情報テーブルを守るには十分でしょう。 - + とを手動で上書きしておくことが思慮深いことといえます。 + どちらか一方でも 0 には決してしないで下さい + (自分のマシンをクラッシュさせたくないのであれば)。 + 両パラメータを 2 秒に設定すれば、 + 攻撃から経路情報テーブルを守るには十分でしょう。 Kerberos および SSH を用いたアクセスの問題 + ssh もしあなたが、Kerberos と ssh を使いたいのだとしたら、 両者に関して言っておかねばならない問題がいくつかあります。 Kerberos 5 は大変優れた認証プロトコルですが、Kerberos 化された telnet や - rlogin は、バイナリストリームを扱う - のに不向きになってしまうようなバグがあります。さらに、デフォル - トでは、Kerberos は オプションを使わない限 - りセッションを暗号化してくれません。 - Ssh では、デフォルトですべてを暗号 - 化してくれます。 + rlogin は、 + バイナリストリームを扱うのに不向きになってしまうようなバグがあります。 + さらに、デフォルトでは、Kerberos は + オプションを使わない限りセッションを暗号化してくれません。 + Ssh では、 + デフォルトですべてを暗号化してくれます。 ssh はあらゆる場面でとても良く働いてくれます。 - ただし、デフォルトで暗号鍵を転送してしまうこと - を除けばです。これはつまり、暗号鍵を持った安全なワークステーショ - ンがあって、この暗号鍵で残りのシステムとアクセスできるようになっ - ている場合に、安全でないマシンへ + ただし、デフォルトで暗号鍵を転送してしまうことを除けばです。 + これはつまり、暗号鍵を持った安全なワークステーションがあって、 + この暗号鍵で残りのシステムとアクセスできるようになっている場合に、 + 安全でないマシンへ ssh 接続を行なうとあなたの暗号鍵を使えてしまうということです。 実際の鍵そのものが見えてしまうわけではありませんが、 - ssh はあなたが login - している間、転送用ポートを作ります。攻撃者が安全でないマシンの - root を破ったら、このポートを使って暗号鍵を取得し、 - この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。 - + ssh はあなたが login している間、転送用ポートを作ります。 + 攻撃者が安全でないマシンの + root を破ったら、 + このポートを使って暗号鍵を取得し、 + この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。 スタッフのログインには、Kerberos を組み合せた ssh を使用することを勧めます。 - Ssh は、Kerberos 対応機能と一緒 - にコンパイルできます。こうすると、見えてしまうかもしれない + Ssh は、Kerberos + 対応機能と一緒にコンパイルできます。 + こうすると、見えてしまうかもしれない ssh 鍵をあまりあてにしないで良いようになります。 また、それと同時に、Kerberos 経由でパスワードを保護することもできます。 ssh 鍵は、安全なマシンからの自動化されたタスク (Kerberos はこの用途には不向きです) のみに使用するべきです。また、 ssh の設定で鍵転送をしないようにするか、あるいは ssh が - authorized_keys ファイル中に書くことを許 - している from=IP/DOMAIN オプションを使用し - て、特定のマシンからログインしてきたときのみ鍵が有効であるよう - にすることも勧めます。 + authorized_keys + ファイル中に書くことを許している from=IP/DOMAIN + オプションを使用して、 + 特定のマシンからログインしてきたときのみ鍵が有効であるようにすることも勧めます。 + DES, Blowfish, MD5 と Crypt - BillSwingle改訂: + + + Bill + Swingle + + 改訂: - - セキュリティ crypt @@ -1111,35 +1191,39 @@ 訳改訂: &a.jp.hino;, 12 March 2001. - &unix; システムにおけるすべてのユーザは、そのアカウントに対応し - た一つのパスワードを持っています。それらのパスワードはユーザ本人 - と本当のオペレーティングシステムのみが知っているべきであるという - ことは明らかでしょう。それらのパスワードを秘密に保っておくために、 - パスワードは一方向ハッシュとして知られる方式で暗 - 号化されます。一方向ハッシュとは、簡単に暗号化はできるが解読は難 - しいという方法です。言葉を換えると、先ほど明らかであると書いたの - は実は正しくないのです: オペレーティングシステム自身は - 本当はパスワードを知らないのです。その代わりに - 暗号化された形でのみパスワードを知っていま - す。素のテキストとしてパスワードを得る唯一の方法は、 - 可能な限りのパスワード空間を検索するという力任せの方法です。 - + &unix; システムにおけるすべてのユーザは、 + そのアカウントに対応した一つのパスワードを持っています。 + それらのパスワードはユーザ本人と本当のオペレーティングシステムのみが知っているべきであるということは明らかでしょう。 + それらのパスワードを秘密に保っておくために、 + パスワードは 一方向ハッシュ + として知られる方式で暗号化されます。 + 一方向ハッシュとは、簡単に暗号化はできるが解読は難しいという方法です。 + 言葉を換えると、 + 先ほど明らかであると書いたのは実は正しくないのです: + オペレーティングシステム自身は + 本当は パスワードを知らないのです。 + その代わりに 暗号化された + 形でのみパスワードを知っています。 + 素のテキスト としてパスワードを得る唯一の方法は、 + 可能な限りのパスワード空間を検索するという力任せの方法です。 - 不幸なことに、&unix; が生まれようとしているときにパスワードを - 安全な形で暗号化できる方式は DES (Data Encryption Standard) - に基づいたものだけでした。このことは米国に住んでいるユーザにとって - は大して問題ではありませんでしたが、DES のソースコードを米国外に - 輸出することはできないという問題がありました。そのために、 - &os; は、米国の法律を守ることと、未だに DES を使っていた他の - &unix; 一族との互換性を保つこととを両立する方法を探し出す必要がありました。 + 不幸なことに、&unix; + が生まれようとしているときにパスワードを安全な形で暗号化できる方式は + DES (Data Encryption Standard) に基づいたものだけでした。 + このことは米国に住んでいるユーザにとっては大して問題ではありませんでしたが、 + DES のソースコードを米国外に輸出することはできないという問題がありました。 + そのために、&os; は、米国の法律を守ることと、 + 未だに DES を使っていた他の &unix; + 一族との互換性を保つこととを両立する方法を探し出す必要がありました。 - その解決方法は、米国のユーザは DES のライブラリをインストー - ルして DES を使用できるが、米国外のユーザは国外に輸出可能な他の - ひとつの暗号化方式を使用することができる、というように暗号化ライ - ブラリを分割することでした。これが &os; がデフォルトの暗号化 - 方式として MD5 を使うようになったいきさつです。MD5 は DES よりも - より安全であると考えられているため、DES をインストールする一番の - 理由は互換性を保つためといえます。 + その解決方法は、米国のユーザは DES + のライブラリをインストールして DES を使用できるが、 + 米国外のユーザは国外に輸出可能な他のひとつの暗号化方式を使用することができる、 + というように暗号化ライブラリを分割することでした。 + これが &os; がデフォルトの暗号化方式として MD5 + を使うようになったいきさつです。MD5 は DES + よりもより安全であると考えられているため、DES + をインストールする一番の理由は互換性を保つためといえます。 暗号化機構を理解する @@ -1148,21 +1232,22 @@ ハッシュ関数に対応しています。デフォルトでは、&os; はパスワードの暗号化に MD5 を利用します。 - &os; がどの暗号化方式を使うようにセットアップされている - かを判断するのは簡単です。 - /etc/master.passwd ファイルの中の暗号化さ - れたパスワードを調べてみるのが一つの方法です。MD5 ハッシュで暗 - 号化されたパスワードは、DES ハッシュで暗号化されたパスワードよ - りも長く、$1$ + &os; + がどの暗号化方式を使うようにセットアップされているかを判断するのは簡単です。 + /etc/master.passwd + ファイルの中の暗号化されたパスワードを調べてみるのが一つの方法です。 + MD5 ハッシュで暗号化されたパスワードは、DES + ハッシュで暗号化されたパスワードよりも長く、 + $1$ という文字で始まるという特徴を持っています。 $2a$ で始まるパスワードは、Blowfish ハッシュ関数で暗号化されています。 - DES のパスワードはこ - れといって識別可能な特徴は持っていませんが、MD5 のパスワードよ - りは短く、そして $ という文字を含ま - ない 64 文字のアルファベットを使って表現されているので、比較的 - 短い文字列でドル記号で始まっていないものはおそらく DES のパス - ワードでしょう。 + DES のパスワードはこれといって識別可能な特徴は持っていませんが、 + MD5 のパスワードよりは短く、そして $ + という文字を含まない 64 + 文字のアルファベットを使って表現されているので、 + 比較的短い文字列でドル記号で始まっていないものはおそらく + DES のパスワードでしょう。 新規パスワードがどちらのパスワード形式になるかは、 /etc/login.conf の中の @@ -1172,12 +1257,12 @@ または blf を設定することができます。 ログインケーパビリティに関するより詳細な情報は、 &man.login.conf.5; マニュアルページをご覧ください。 - ワンタイムパスワード + ワンタイムパスワード セキュリティ @@ -1229,31 +1314,32 @@ システムにとって重要な 2 種類のデータがあります。一つは シード (seed: 種) または キー (key: 鍵) と呼ばれるもので、2 つの文字と - 5 つの数字で構成されます。もう一つは シーケンス番号 (iteration - count) で、1 から 100 までの整数です。OPIE はここまで - に述べたデータを利用してワンタイムパスワードを生成します。その方 - 法は、まずシードと秘密のパスフレーズを連結し、それに対してシーケ - ンス番号の回数だけ MD5 ハッシュを繰り返し計算します。 + 5 つの数字で構成されます。もう一つは シーケンス番号 + (iteration count) で、1 から 100 までの整数です。OPIE + はここまでに述べたデータを利用してワンタイムパスワードを生成します。 + その方法は、まずシードと秘密のパスフレーズを連結し、 + それに対してシーケンス番号の回数だけ MD5 ハッシュを繰り返し計算します。 そしてその結果を 6 つの短い英単語に変換します。 認証システム (一次的には PAM) は、前回最後に受け付けたワンタイムパスワードを記録しています。 - そして、その前回 - のワンタイムパスワードと、ユーザが入力したワンタイムパスワードを - 1 回ハッシュ関数にかけた結果とが一致した場合に、このユーザは認証 - されます。一方向ハッシュ関数を使っているので、もし正しく認証され - たワンタイムパスワードが一回盗聴されたとしても、次回以降に使われ - る複数のワンタイムパスワードを生成することは不可能です。シーケ - ンス番号はログインが成功するたびに一つずつ減らされて、ユーザとロ - グインプログラムの間で同期が取られます。シーケンス番号が 1 まで - 減ったら、OPIE を再度初期化する必要があります。 + そして、その前回のワンタイムパスワードと、 + ユーザが入力したワンタイムパスワードを + 1 回ハッシュ関数にかけた結果とが一致した場合に、 + このユーザは認証されます。 + 一方向ハッシュ関数を使っているので、 + もし正しく認証されたワンタイムパスワードが一回盗聴されたとしても、 + 次回以降に使われる複数のワンタイムパスワードを生成することは不可能です。 + シーケンス番号はログインが成功するたびに一つずつ減らされて、 + ユーザとログインプログラムの間で同期が取られます。 + シーケンス番号が 1 まで減ったら、 + OPIE を再度初期化する必要があります。 - 次に、それぞれのシステムで関連する - いくつかのプログラムについて説明します。 + 次に、 + それぞれのシステムで関連するいくつかのプログラムについて説明します。 opiekey プログラムは、シーケンス番号と、シードと、 秘密のパスフレーズを受け付けて、ワンタイムパスワード 1 つ、 または一連のワンタイムパスワードの一覧を生成します。 - opiepasswd - プログラムは、OPIE + opiepasswd プログラムは、OPIE を初期化するのに使用され、また秘密のパスフレーズ、 シーケンス番号やシードを変更するためにも使用されます。 このプログラムを実行するには、秘密のパスフレーズか、 @@ -1264,8 +1350,8 @@ プログラムを起動したユーザの現在のシーケンス番号とシードを表示します。 この文書では、4 種類の異なる操作について説明します。 - 1 つ目は、 - opiepasswd を信頼できる通信路上で利用して、 + 1 つ目は、opiepasswd + を信頼できる通信路上で利用して、 最初にワンタイムパスワードを設定したり、 秘密のパスフレーズやシードを変更する操作です。 2 つ目は、同じことを行うために @@ -1279,8 +1365,8 @@ メモしたり印刷したりして携帯し、 信頼できる通信路が一切ないところで利用することができます。 (訳注: ワンタイムパスワードを記録した紙をなくさないこと! - 電話番号や - IP アドレス、ユーザ名を一緒にメモしていたら最悪です!!) + 電話番号や + IP アドレス、ユーザ名を一緒にメモしていたら最悪です!!) 信頼できる通信路での初期化 @@ -1303,27 +1389,24 @@ Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID unfurl OTP key is 499 to4268 -MOS MALL GOAT ARM AVID COED - +MOS MALL GOAT ARM AVID COED Enter new secret pass phrase: または Enter secret password: というプロンプトに対して、 - あなたが考えた秘密のパスフレーズを入力します。このパスフ - レーズはログインするときに使うものではなく、ログインするときに - 使うワンタイムパスワードを生成するために使うものであることを覚 - えておいてください。ID から始まる行は、 - 1 回分のパラメータで、 + あなたが考えた秘密のパスフレーズを入力します。 + このパスフレーズはログインするときに使うものではなく、 + ログインするときに使うワンタイムパスワードを生成するために使うものであることを覚えておいてください。 + ID から始まる行は、1 回分のパラメータで、 あなたのログイン名とシーケンス番号とシードです。 (訳注: keyinit コマンドは 次回にログインするときに使えるパラメータを参考のためにここで表示します)。 システムにログインするときには、 システム側が自動的にこれらのパラメータを表示してくれますから、 - これらのパラメータを - 覚えておく必要はありません。最後の行が、今述べたパラメータと入力 - された秘密のパスフレーズから計算されたワンタイムパスワードです。 - この例を実行した後、次にログインするときに打ち込むべきワンタイ - ムパスワードがこれです。 + これらのパラメータを覚えておく必要はありません。 + 最後の行が、今述べたパラメータと入力された秘密のパスフレーズから計算されたワンタイムパスワードです。 + この例を実行した後、 + 次にログインするときに打ち込むべきワンタイムパスワードがこれです。 @@ -1334,13 +1417,14 @@ MOS MALL GOAT ARM AVID COED プログラムを実行するための信頼できる通信路を用意しておく必要があります。 たとえばそれは、 信頼できるマシンのシェルプロンプトだったりするでしょう。 - (訳注: ここでの通信路とはマシンそのものになりま - す。信頼できるマシンとは、信頼できる人がしっかり管理しているマ - シンということです)。他に準備しておくものとして、シーケンス番 - 号 (100 は適切な値といえるでしょう) と、場合によっては自分で考 - えた、またはランダムに生成されたシードがあります。(あなたが - S/Key を初期化しようとしているマシンへの) 信頼できない通信路を - 使うときには、opiepasswd + (訳注: ここでの通信路とはマシンそのものになります。 + 信頼できるマシンとは、 + 信頼できる人がしっかり管理しているマシンということです)。 + 他に準備しておくものとして、シーケンス番号 + (100 は適切な値といえるでしょう) と、場合によっては自分で考えた、 + またはランダムに生成されたシードがあります。(あなたが + S/Key を初期化しようとしているマシンへの) + 信頼できない通信路を使うときには、opiepasswd コマンドを以下のように使用します。 &prompt.user; opiepasswd @@ -1361,8 +1445,8 @@ LINE PAP MILK NELL BUOY TROY デフォルトのシードで構わなければ、Return - を押してください。次に、アクセスパスワードを入れる前に、あらか - じめ用意しておいた信頼できる通信路へ移って、 + を押してください。次に、アクセスパスワードを入れる前に、 + あらかじめ用意しておいた信頼できる通信路へ移って、 先ほどと同じパラメータを入力します。 &prompt.user; opiekey 498 to4268 @@ -1398,8 +1482,8 @@ Password: パスワードプロンプトに対して、何も入力せずに Return を押すとエコーモードに切り替わります。 つまりタイプした文字がそのまま見えるようになるのです。 - これは、紙に印刷していたりするワンタイムパスワードを - 手で入力しなければならない場合に特に役立つ機能です。 + これは、 + 紙に印刷していたりするワンタイムパスワードを手で入力しなければならない場合に特に役立つ機能です。 MS-DOS Windows @@ -1410,7 +1494,8 @@ Password: これは、opiekey プログラムを使える信頼できるマシン上で行わなければなりません。 (これらのプログラムには DOS や &windows;, &macos; 版があります)。 - どちらも、コマンドラインからシーケンス番号とシードを指定しなければなりません。 + どちらも、 + コマンドラインからシーケンス番号とシードを指定しなければなりません。 ログインしようとしているマシンのログインプロンプトから直接カットアンドペーストすると楽でしょう。 信頼できるシステムで @@ -1445,18 +1530,20 @@ Enter secret pass phrase: <secret password> 29: RIO ODIN GO BYE FURY TIC 30: GREW JIVE SAN GIRD BOIL PHI - という引数によって 5 個のワンタイム - パスワードを順に生成します。ここで は、最 - 後のシーケンス番号となるべき数字です。出力は普通に使う順番とは - 逆に出力されていることに注意してください - (訳注: 一番最初に使うワンタイムパスワードは一番最後に出力され - たものです)。この結果をカットアンドペーストして - lpr コマンドを使って印刷すると よいでしょう。 - もしあなたがセキュリティに偏執するなら、この結果を紙と鉛筆を使っ - て手で書き移した方がよいかもしれません。ここで、出力の各行はシー - ケンス番号とそれに対応する一回分のワンタイムパスワードです。 - 消費済みの ワンタイムパスワードの行をペンで消していくと便利で - しょう。 + という引数によって 5 + 個のワンタイムパスワードを順に生成します。 + ここで は、 + 最後のシーケンス番号となるべき数字です。出力は普通に使う順番とは + 逆 + に出力されていることに注意してください (訳注: + 一番最初に使うワンタイムパスワードは一番最後に出力されたものです)。 + この結果をカットアンドペーストして + lpr コマンドを使って印刷するとよいでしょう。 + もしあなたがセキュリティに偏執するなら、 + この結果を紙と鉛筆を使って手で書き移した方がよいかもしれません。 + ここで、 + 出力の各行はシーケンス番号とそれに対応する一回分のワンタイムパスワードです。 + 消費済みのワンタイムパスワードの行をペンで消していくと便利でしょう。 @@ -1469,7 +1556,7 @@ Enter secret pass phrase: <secret password> このファイルの詳細や、 このファイルを使用する際に考慮すべきセキュリィについては &man.opieaccess.5; を確認してください。 - + 以下は opieaccess ファイルの例です。 permit 192.168.0.0 255.255.0.0 @@ -1477,11 +1564,10 @@ Enter secret pass phrase: <secret password> この行では、(なりすましされやすい) IP ソースアドレスが、 ある値やマスクにマッチするユーザに対して、 &unix; パスワードをいつでも許可します。 - + もし opieaccess のどのルールにも一致しなければ、 デフォルトでは非 OPIE ログインは使えません。 - @@ -1530,9 +1616,9 @@ Enter secret pass phrase: <secret password> ファイアウォールおよび他のセキュリティ設定と組み合わせて使うことができ、 システムを守るための追加のレイヤとして上手く機能します。 - この設定は inetd の設定の拡張なので、 - inetd の設定 - 章をすでに読んでいることを想定しています。 + この設定は inetd + の設定の拡張なので、inetd + の設定 章をすでに読んでいることを想定しています。 &man.inetd.8; により起動されるプログラムは、正確には、 @@ -1604,14 +1690,14 @@ qpopper : ALL : allow これを行うには、&man.kill.1; コマンドを使うか、 restart パラメータとともに、 /etc/rc.d/inetd を使ってください。 - + - - 高度な設定 + + 高度な設定 TCP Wrappers で高度な設定もできます。 - 接続を取り扱う以上の制御を行うことができるのです。 - ある時は、接続しているホストまたはデーモンにコメントを返すことが良い考えのことがあります。 + 接続を取り扱う以上の制御を行うことができるのです。ある時は、 + 接続しているホストまたはデーモンにコメントを返すことが良い考えのことがあります。 別の場合では、おそらくログファイルを記録したり、 管理者にメールで送る必要があることもあるでしょう。 またその他の状況としては、 @@ -1621,7 +1707,7 @@ qpopper : ALL : allow で可能となります。 以下の 2 つの節では、 このような状況への対応について触れています。 - + 外部コマンド @@ -1671,8 +1757,8 @@ ALL : .example.com \ /var/log/connections.log) \ : deny - この行は、 - *.example.com + この行は、*.example.com ドメインからの接続をすべて拒否します。 同時にホスト名、IP アドレスおよびアクセスを試みたデーモンが、 @@ -1807,6 +1893,7 @@ sendmail : PARANOID : deny 歴史 + Kerberos5 歴史 @@ -1853,12 +1940,13 @@ sendmail : PARANOID : deny &os; の base インストールに含まれています。 幅広い読者を対象とするために、以下の説明では - &os; に含まれている Heimdal - ディストリビューションの使用を想定しています。 + &os; に含まれている Heimdal + ディストリビューションの使用を想定しています。 Heimdal <acronym>KDC</acronym> の設定 + Kerberos5 鍵配布センター @@ -1875,18 +1963,18 @@ sendmail : PARANOID : deny 信頼されています。 そのため、厳重なセキュリティに対する配慮が必要となります。 - Kerberos + Kerberos サーバの実行にコンピュータのリソースは必要ありませんが、 セキュリティの観点から、KDC としてのみ機能する専用のコンピュータが推奨されます。 - KDC を設定するにあたって、 + KDC を設定するにあたって、 KDC として動作するために、 適切に /etc/rc.conf が設定されていること (システムを反映するようにパスを調整する必要があります) を確認してください。 - kerberos5_server_enable="YES" + kerberos5_server_enable="YES" kadmind5_server_enable="YES" 次に、Kerberos @@ -1905,8 +1993,8 @@ kadmind5_server_enable="YES" /etc/krb5.conf ファイルの中では、 KDC は、 - 完全修飾されたホスト名 - kerberos.example.org + 完全修飾されたホスト名 kerberos.example.org を持つことが想定されていることに注意してください。 KDC が異なるホスト名である場合には、 名前の解決が行われるように、適切に CNAME (エイリアス) @@ -1928,13 +2016,14 @@ kadmind5_server_enable="YES" _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. -_kerberos IN TXT EXAMPLE.ORG +_kerberos IN TXT EXAMPLE.ORG + - クライアントが、 - Kerberos サービスを見つけるためには、 - /etc/krb5.conf を完全に設定するか、 - /etc/krb5.conf を最低限に設定し、 + クライアントが、 + Kerberos サービスを見つけるためには、 + /etc/krb5.conf を完全に設定するか、 + /etc/krb5.conf を最低限に設定し、 さらに DNS サーバを適切に設定する 必要 があります。 @@ -2007,79 +2096,78 @@ Credentials cache: FILE:/tmp/krb5cc_500 Issued Expires Principal Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG - 必要がなくなった時には、チケットを破棄できます。 + 必要がなくなった時には、チケットを破棄できます。 - &prompt.user; kdestroy - + &prompt.user; kdestroy + - - Heimdal <application>Kerberos</application> - サービスを有効にする。 + + Heimdal <application>Kerberos</application> + サービスを有効にする。 - - Kerberos5 - Enabling サービス - + + Kerberos5 + Enabling サービス + - 最初に Kerberos - の設定ファイル /etc/krb5.conf - のコピーが必要です。 - コピーを行うには、KDC から、 - クライアントコンピュータへ - (&man.scp.1; のようなネットワークユーティリティを使うか、 - 物理的にフロッピーディスクを使って) - 安全な方法でコピーをしてください。 + 最初に Kerberos + の設定ファイル /etc/krb5.conf + のコピーが必要です。 + コピーを行うには、KDC から、 + クライアントコンピュータへ + (&man.scp.1; のようなネットワークユーティリティを使うか、 + 物理的にフロッピーディスクを使って) + 安全な方法でコピーをしてください。 - 次に /etc/krb5.keytab - ファイルが必要となります。 - これは、Kerberos - 化されたデーモンを提供するサーバとワークステーションの間での大きな違いです - — サーバは、 - keytab ファイルを持っている必要があります。 - このファイルには、サーバのホスト鍵が含まれています。 - この鍵により、ホストおよび - KDC が他の身元の検証ができます。 - 鍵が公開されてしまうと、 - サーバのセキュリティが破れてしまうため、 - このファイルは安全にサーバに転送しなければなりません。 - このことは、FTP - のようにテキストチャネルでの転送は、 - まったく好ましくないことを意味しています。 + 次に /etc/krb5.keytab + ファイルが必要となります。 + これは、Kerberos + 化されたデーモンを提供するサーバとワークステーションの間での大きな違いです + — サーバは、 + keytab ファイルを持っている必要があります。 + このファイルには、サーバのホスト鍵が含まれています。 + この鍵により、ホストおよび + KDC が他の身元の検証ができます。 + 鍵が公開されてしまうと、 + サーバのセキュリティが破れてしまうため、 + このファイルは安全にサーバに転送しなければなりません。 + このことは、FTP + のようにテキストチャネルでの転送は、 + まったく好ましくないことを意味しています。 - 一般的には、kadmin プログラムを使って、 - keytab をサーバに転送します。 - kadmin を使って - (KDC 側の - krb5.keytab に) - ホストプリンシパルを作成することも必要なので便利です。 + 一般的には、kadmin プログラムを使って、 + keytab をサーバに転送します。 + kadmin を使って + (KDC 側の + krb5.keytab に) + ホストプリンシパルを作成することも必要なので便利です。 - すでにチケットを入手し、 - そのチケットは、 - kadmin インタフェースで使用できることが - kadmind.acl - で許可されている必要があります。 - アクセスコントロールリストの設計の詳細については、 - Heimdal info ページ (info heimdal) の - Remote administration - というタイトルの章をご覧ください。 - リモートからの - kadmin アクセスを有効にしたくない場合は、 - 安全に (ローカルコンソール、&man.ssh.1; もしくは - Kerberos &man.telnet.1; を用いて) - KDC に接続し、 - kadmin -l を使用して、 - ローカルで管理作業を行ってください。 + すでにチケットを入手し、そのチケットは、 + kadmin インタフェースで使用できることが + kadmind.acl + で許可されている必要があります。 + アクセスコントロールリストの設計の詳細については、 + Heimdal info ページ (info heimdal) の + Remote administration + というタイトルの章をご覧ください。 + リモートからの + kadmin アクセスを有効にしたくない場合は、 + 安全に (ローカルコンソール、&man.ssh.1; もしくは + Kerberos &man.telnet.1; を用いて) + KDC に接続し、 + kadmin -l を使用して、 + ローカルで管理作業を行ってください。 - /etc/krb5.conf - ファイルをインストールしたら、 - Kerberos サーバから、 - kadmin を使うことができます。 - add --random-key コマンドを使うと、 - サーバのホストプリンシパルを追加できます。 - そして、ext コマンドを用いて、 - サーバのホストプリンシパルを keytab に抽出してください。 + /etc/krb5.conf + ファイルをインストールしたら、 + Kerberos サーバから、 + kadmin を使うことができます。 + add --random-key コマンドを使うと、 + サーバのホストプリンシパルを追加できます。 + そして、ext コマンドを用いて、 + サーバのホストプリンシパルを keytab に抽出してください。 - &prompt.root; kadmin + &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: @@ -2088,523 +2176,526 @@ Attributes []: kadmin> ext host/myserver.example.org kadmin> exit - ext コマンド (extract - の省略形) は、デフォルトでは、抽出された鍵を - /etc/krb5.keytab に保存します。 + ext コマンド (extract + の省略形) は、デフォルトでは、抽出された鍵を + /etc/krb5.keytab に保存します。 - KDC 上で kadmind - を (おそらくセキュリティ上の理由から) 走らせていない場合で、 - リモートから kadmin に接続出来ない場合には、 - ホストプリンシパル (host/myserver.EXAMPLE.ORG) - を直接 KDC 上で追加し、 - その後、以下のように - (KDC 上の - /etc/krb5.keytab の上書きを避けるため)、 - 一時ファイルに抽出してください。 + KDC 上で kadmind + を (おそらくセキュリティ上の理由から) 走らせていない場合で、 + リモートから kadmin に接続出来ない場合には、 + ホストプリンシパル (host/myserver.EXAMPLE.ORG) + を直接 KDC 上で追加し、 + その後、以下のように + (KDC 上の + /etc/krb5.keytab の上書きを避けるため)、 + 一時ファイルに抽出してください。 - &prompt.root; kadmin + &prompt.root; kadmin kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit - その後、keytab を安全に (たとえば - scp またはフロッピーを使って) - サーバコンピュータにコピーしてください。 - KDC 上の keytab を上書きすることを避けるため、 - デフォルトとは異なる名前を指定してください。 + その後、keytab を安全に (たとえば + scp またはフロッピーを使って) + サーバコンピュータにコピーしてください。 + KDC 上の keytab を上書きすることを避けるため、 + デフォルトとは異なる名前を指定してください。 - これでサーバは、 - (krb5.conf ファイルにより) - KDC と通信ができるようになりました。 - そして、(krb5.keytab ファイルによって) - 身元を証明できるようになったので、 - Kerberos - サービスを有効にする準備が出来ました。 - この例では、以下の行を - /etc/inetd.conf に加え、 - telnet - サービスを有効にしてください。その後、 - /etc/rc.d/inetd restart にて - &man.inetd.8; サービスを再起動します。 + これでサーバは、 + (krb5.conf ファイルにより) + KDC と通信ができるようになりました。 + そして、(krb5.keytab ファイルによって) + 身元を証明できるようになったので、 + Kerberos + サービスを有効にする準備が出来ました。 + この例では、以下の行を + /etc/inetd.conf に加え、 + telnet + サービスを有効にしてください。その後、 + /etc/rc.d/inetd restart にて + &man.inetd.8; サービスを再起動します。 - telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user + telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user - 重要な箇所は、ユーザに -a - (認証を表す) が設定されていることです。 - 詳細については、 - &man.telnetd.8; マニュアルページを参照してください。 - + 重要な箇所は、ユーザに -a + (認証を表す) が設定されていることです。 + 詳細については、 + &man.telnetd.8; マニュアルページを参照してください。 + - - Heimdal <application>Kerberos</application> - クライアントを有効にする + + Heimdal <application>Kerberos</application> + クライアントを有効にする - - Kerberos5 - クライアントの設定 - + + Kerberos5 + クライアントの設定 + - クライアントコンピュータの設定は、 - ほとんど取るに足らないくらいに簡単です。 - Kerberos の設定がうまくいっていれば、 - /etc/krb5.conf に置かれている - Kerberos - の設定ファイルのみが必要です。 - セキュリティ的に安全な方法で、KDC - からクライアントコンピュータへ単にコピーしてください。 + クライアントコンピュータの設定は、 + ほとんど取るに足らないくらいに簡単です。 + Kerberos の設定がうまくいっていれば、 + /etc/krb5.conf に置かれている + Kerberos + の設定ファイルのみが必要です。 + セキュリティ的に安全な方法で、KDC + からクライアントコンピュータへ単にコピーしてください。 - クライアントから、kinit, - klist および - kdestroy を使用し、 - 上記で作成したプリンシパルに対するチケットの入手、表示、 - 削除を行い、クライアントコンピュータを試験してください。 - Kerberos - アプリケーションを使って Kerberos - が有効なサーバに接続することもできるはずです。 - もしうまく機能しない場合でも、チケットを入手できるのであれば、 - 問題はおそらくサーバにあり、 - クライアントまたは KDC - の問題ではないと考えられます。 + クライアントから、kinit, + klist および + kdestroy を使用し、 + 上記で作成したプリンシパルに対するチケットの入手、表示、 + 削除を行い、クライアントコンピュータを試験してください。 + Kerberos + アプリケーションを使って Kerberos + が有効なサーバに接続することもできるはずです。 + もしうまく機能しない場合でも、チケットを入手できるのであれば、 + 問題はおそらくサーバにあり、 + クライアントまたは KDC + の問題ではないと考えられます。 - telnet - のようなアプリケーションを試験する際には、 - (&man.tcpdump.1; といった) パケットスニファを使用して、 - パスワードが平文で送られていないことを確認してください。 - -x オプションで - telnet を利用すると、 - (ssh のように) - すべてのデータストリームが暗号化されます。 + telnet + のようなアプリケーションを試験する際には、 + (&man.tcpdump.1; といった) パケットスニファを使用して、 + パスワードが平文で送られていないことを確認してください。 + -x オプションで + telnet を利用すると、 + (ssh のように) + すべてのデータストリームが暗号化されます。 - デフォルトでは、Heimdal インストールの - 最小 と考えられる、コア以外の - Kerberos - クライアントアプリケーションもインストールされます。 - telnet は、 - Kerberos - 化された唯一のサービスです。 + デフォルトでは、Heimdal インストールの + 最小 と考えられる、コア以外の + Kerberos + クライアントアプリケーションもインストールされます。 + telnet は、 + Kerberos + 化された唯一のサービスです。 - Heimdal port は、 - Kerberos 化されている - ftp, rsh, - rcp, rlogin - および他のあまり一般的ではないプログラムといった、 - インストールされていないクライアントアプリケーションをインストールします。 - MIT port も、すべての - Kerberos - クライアントアプリケーションをインストールします。 - + Heimdal port は、 + Kerberos 化されている + ftp, rsh, + rcp, rlogin + および他のあまり一般的ではないプログラムといった、 + インストールされていないクライアントアプリケーションをインストールします。 + MIT port も、すべての + Kerberos + クライアントアプリケーションをインストールします。 + - - ユーザ設定ファイル: <filename>.k5login</filename> - および <filename>.k5users</filename> + + ユーザ設定ファイル: <filename>.k5login</filename> + および <filename>.k5users</filename> - - .k5login - + + .k5login + - - .k5users - + + .k5users + - レルムのユーザは、一般的には、 - (tillman - のような) ローカルユーザアカウントに対応する - (tillman@EXAMPLE.ORG - といった) Kerberos - プリンシパルを持ちます。 - telnet - のようなクライアントアプリケーションは、 - ユーザ名もしくはプリンシパルを通常必要としません。 + レルムのユーザは、一般的には、 + (tillman + のような) ローカルユーザアカウントに対応する + (tillman@EXAMPLE.ORG + といった) Kerberos + プリンシパルを持ちます。 + telnet + のようなクライアントアプリケーションは、 + ユーザ名もしくはプリンシパルを通常必要としません。 - しかしながら、時々 - Kerberos - プリンシパルに対応しないローカルユーザアカウントへのアクセスが必要となることがあります。 - たとえば、 - tillman@EXAMPLE.ORG - が、ローカルユーザアカウント - webdevelopers - へのアクセスが必要となることがあります。 - そして、他のプリンシパルが同じローカルアカウントにアクセスが必要になることもあります。 + しかしながら、時々 + Kerberos + プリンシパルに対応しないローカルユーザアカウントへのアクセスが必要となることがあります。 + たとえば、 + tillman@EXAMPLE.ORG + が、ローカルユーザアカウント + webdevelopers + へのアクセスが必要となることがあります。 + そして、他のプリンシパルが同じローカルアカウントにアクセスが必要になることもあります。 - ユーザのホームディレクトリに置かれた - .k5login および - .k5users ファイルによって - (.hosts および .rhosts - の強力な組み合わせのように)、この問題を解決出来ます。 - たとえば、以下の行を含む - .k5login を + ユーザのホームディレクトリに置かれた + .k5login および + .k5users ファイルによって + (.hosts および .rhosts + の強力な組み合わせのように)、この問題を解決出来ます。 + たとえば、以下の行を含む + .k5login を - tillman@example.org + tillman@example.org jdoe@example.org - ローカルユーザ - webdevelopers - のホームディレクトリに置くと、 - 一覧にある両方のプリンシパルは、 - 共有のパスワードを必要としなくても、 - このアカウントにアクセス出来ます。 + ローカルユーザ + webdevelopers + のホームディレクトリに置くと、 + 一覧にある両方のプリンシパルは、 + 共有のパスワードを必要としなくても、 + このアカウントにアクセス出来ます。 - これらのコマンドのマニュアルページを読むことが推奨されます。 - ksu マニュアルページには、 - .k5users の説明があります。 - + これらのコマンドのマニュアルページを読むことが推奨されます。 + ksu マニュアルページには、 + .k5users の説明があります。 + - - <application>Kerberos</application> Tips, Tricks, およびトラブルシューティング + + <application>Kerberos</application> + Tips, Tricks, およびトラブルシューティング - - Kerberos5 - トラブルシューティング - + + Kerberos5 + トラブルシューティング + - - - Heimdal または MIT - Kerberos ports - のどちらを使う場合でも、 - PATH 環境変数は、 - Kerberos 版のクライアント - アプリケーションが、 - システムにあるアプリケーションより先に見つかるように設定されていることを確認してください。 - + + + Heimdal または MIT + Kerberos ports + のどちらを使う場合でも、 + PATH 環境変数は、 + Kerberos 版のクライアント + アプリケーションが、 + システムにあるアプリケーションより先に見つかるように設定されていることを確認してください。 + - - レルムにあるすべてのコンピュータの間で時刻が同期していますか？ - 時刻が同期していないと認証に失敗してしまいます。 - NTP を用いた、時刻の同期方法については、 - をご覧ください。 - + + レルムにあるすべてのコンピュータの間で時刻が同期していますか？ + 時刻が同期していないと認証に失敗してしまいます。 + NTP を用いた、時刻の同期方法については、 + をご覧ください。 + - - MIT および Heimdal 間の運用は、 - 標準化されていないプロトコル kadmin を除き、 - うまく機能します。 - + + MIT および Heimdal 間の運用は、 + 標準化されていないプロトコル kadmin を除き、 + うまく機能します。 + - - ホスト名を変更する際は、 - host/ - プリンシパルを変更し、keytab をアップデートする必要があります。 - Apache の - www/mod_auth_kerb - で使われる - www/ - プリンシパルのような特別な - keytab エントリでも必要となります。 - + + ホスト名を変更する際は、 + host/ + プリンシパルを変更し、keytab をアップデートする必要があります。 + Apache の + www/mod_auth_kerb + で使われる + www/ + プリンシパルのような特別な + keytab エントリでも必要となります。 + - - レルムの中のすべてのホストは、DNS - において (もしくは、最低限/etc/hosts - の中で)、(正引きおよび逆引き両方で) - 名前解決できる必要があります。 - CNAME は動作しますが、A および PTR レコードは、 - 正しく適切な位置に記述されている必要があります。 - エラーメッセージは、 - 次の例のように、直感的に原因が分かるようなものではありません。 - Kerberos5 refuses authentication because Read req - failed: Key table entry not found. - + + レルムの中のすべてのホストは、DNS + において (もしくは、最低限/etc/hosts + の中で)、(正引きおよび逆引き両方で) + 名前解決できる必要があります。 + CNAME は動作しますが、A および PTR レコードは、 + 正しく適切な位置に記述されている必要があります。 + エラーメッセージは、 + 次の例のように、直感的に原因が分かるようなものではありません。 + Kerberos5 refuses authentication because Read + req failed: Key table entry not + found. + - - KDC - に対しクライアントとして振る舞うオペレーティングシステムの中には、 - ksu に対して、 - root 権限に - setuid を許可しないものがあります。 - この設定では、 - ksu は動作しないことを意味します。 - セキュリティの観点からは好ましい考えですが、 - 厄介です。これは - KDC のエラーではありません。 - + + KDC + に対しクライアントとして振る舞うオペレーティングシステムの中には、 + ksu に対して、 + root 権限に + setuid を許可しないものがあります。 + この設定では、 + ksu は動作しないことを意味します。 + セキュリティの観点からは好ましい考えですが、 + 厄介です。これは + KDC のエラーではありません。 + - - MIT - Kerberos において、 - プリンシパルが、デフォルトの 10 - 時間を超えるチケットの有効期限としたい場合には、 - kadmin で - modify_principal を使って、 - 対象のプリンシパルおよび - krbtgt - プリンシパル両方の有効期限の最大値を変更してください。 - プリンシパルは、 - kinit で - -l オプションを使用して、 - 長い有効期限のチケットを要求できます。 - + + MIT + Kerberos において、 + プリンシパルが、デフォルトの 10 + 時間を超えるチケットの有効期限としたい場合には、 + kadmin で + modify_principal を使って、 + 対象のプリンシパルおよび + krbtgt + プリンシパル両方の有効期限の最大値を変更してください。 + プリンシパルは、 + kinit で + -l オプションを使用して、 + 長い有効期限のチケットを要求できます。 + - - トラブルシューティングのために、 - KDC でパケットスニファを走らせ、 - そして、ワークステーションから - kinit を実行すると、 - kinit を実行するやいなや、 - TGT が送られてきます。 - — - あなたがパスワードを入力し終わる前でも! - これに関する説明は、以下の通りです。 - Kerberos サーバは、 - いかなる未承認のリクエストに対して、 - 自由に TGT (Ticket Granting - Ticket) を送信します。しかしながら、すべての - TGT は、 - ユーザのパスワードから生成された鍵により、暗号化されています。 - そのため、ユーザがパスワードを入力した時には、 - パスワードは KDC には送られません。 - このパスワードは、kinit がすでに入手した - TGT の復号化に使われます。 - もし、復号化の結果、 - 有効なチケットで有効なタイムスタンプの場合には、 - ユーザは、有効な Kerberos - クレデンシャルを持ちます。 - このクレデンシャルには、 - Kerberos - サーバ自身の鍵により暗号化された実際の - ticket-granting ticket とともに、将来 - Kerberos - サーバと安全な通信を確立するためのセッション鍵が含まれています。 - この暗号の 2 番目のレイヤは、ユーザには知らされませんが、 - Kerberos サーバが、 - 各 TGT - の真偽の検証を可能にしている部分です。 - + + トラブルシューティングのために、 + KDC でパケットスニファを走らせ、 + そして、ワークステーションから + kinit を実行すると、 + kinit を実行するやいなや、 + TGT が送られてきます。 + — + あなたがパスワードを入力し終わる前でも! + これに関する説明は、以下の通りです。 + Kerberos サーバは、 + いかなる未承認のリクエストに対して、 + 自由に TGT (Ticket Granting + Ticket) を送信します。しかしながら、すべての + TGT は、 + ユーザのパスワードから生成された鍵により、暗号化されています。 + そのため、ユーザがパスワードを入力した時には、 + パスワードは KDC には送られません。 + このパスワードは、kinit がすでに入手した + TGT の復号化に使われます。 + もし、復号化の結果、 + 有効なチケットで有効なタイムスタンプの場合には、 + ユーザは、有効な Kerberos + クレデンシャルを持ちます。 + このクレデンシャルには、 + Kerberos + サーバ自身の鍵により暗号化された実際の + ticket-granting ticket とともに、将来 + Kerberos + サーバと安全な通信を確立するためのセッション鍵が含まれています。 + この暗号の 2 番目のレイヤは、ユーザには知らされませんが、 + Kerberos サーバが、 + 各 TGT + の真偽の検証を可能にしている部分です。 + - - (たとえば一週間といった) - 長い有効期限のチケットを使いたい場合で、 - OpenSSH を使って、 - チケットが保存されているコンピュータに接続しようとする場合は、 - Kerberos - が - sshd_config において - no と設定されているか、 - チケットが、ログアウト時に削除されることを確認してください。 - + + (たとえば一週間といった) + 長い有効期限のチケットを使いたい場合で、 + OpenSSH を使って、 + チケットが保存されているコンピュータに接続しようとする場合は、 + Kerberos + が + sshd_config において + no と設定されているか、 + チケットが、ログアウト時に削除されることを確認してください。 + - - ホストプリンシパルも長い有効期限のチケットを持てることを覚えておいてください。 - もし、ユーザプリンシパルが 1 週間の有効期限を持ち、 - 接続しているホストが、9 時間の有効期限を持っている場合には、 - キャッシュのホストプリンシパル (の鍵) の有効期限が切れてしまい、 - 想定したように、チケットキャッシュが振る舞わないことが起こりえます。 - + + ホストプリンシパルも長い有効期限のチケットを持てることを覚えておいてください。 + もし、ユーザプリンシパルが 1 週間の有効期限を持ち、 + 接続しているホストが、9 時間の有効期限を持っている場合には、 + キャッシュのホストプリンシパル (の鍵) の有効期限が切れてしまい、 + 想定したように、 + チケットキャッシュが振る舞わないことが起こりえます。 + - - 特定の問題のあるパスワードが使われることを避けるために - (kadmind のマニュアルページでは、 - この点について簡単に触れています)、 - krb5.dict ファイルを設定する時には、 - パスワードポリシが割り当てられたプリンシパルにのみ適用されることに注意してください。 - krb5.dict ファイルの形式は簡単です。 - : 一行に一つの文字列が置かれています。 - /usr/share/dict/words - にシンボリックリンクを作成することは、有効です。 - - + + 特定の問題のあるパスワードが使われることを避けるために + (kadmind のマニュアルページでは、 + この点について簡単に触れています)、 + krb5.dict ファイルを設定する時には、 + パスワードポリシが割り当てられたプリンシパルにのみ適用されることに注意してください。 + krb5.dict ファイルの形式は簡単です。 + : 一行に一つの文字列が置かれています。 + /usr/share/dict/words + にシンボリックリンクを作成することは、有効です。 + + + - + + <acronym>MIT</acronym> port との違いについて - - <acronym>MIT</acronym> port との違いについて + MIT + とインストールされている Heimdal 版の大きな違いは、 + kadmin に関連しています。 + このプログラムは、異なる (ただし等価な) コマンド群を持ち、そして、 + 異なるプロトコルを使用します。 + もし KDC に MIT + を使用している場合には、 + Heimdal kadmin + プログラムを使って KDC をリモートから + (この場合は、逆も同様に) 管理できないことを意味しています。 - MIT - とインストールされている Heimdal 版の大きな違いは、 - kadmin に関連しています。 - このプログラムは、異なる (ただし等価な) コマンド群を持ち、そして、 - 異なるプロトコルを使用します。 - もし KDC に MIT - を使用している場合には、 - Heimdal kadmin - プログラムを使って KDC をリモートから - (この場合は、逆も同様に) 管理できない - ことを意味しています。 + クライアントアプリケーションでは、同じタスクを行う際に、 + 若干異なるコマンドラインのオプションが必要となることもあります。 + MIT + Kerberos ウェブサイト + () + に書かれているガイドに従うことが推奨されます。 + path の問題について注意してください。 + MIT port はデフォルトで + /usr/local/ + にインストールします。 + そのため、もし PATH + 環境変数においてシステムのディレクトが最初に書かれている場合には、 + MIT 版ではなく、通常の + システムアプリケーションが動いてしまいます。 - クライアントアプリケーションでは、同じタスクを行う際に、 - 若干異なるコマンドラインのオプションが必要となることもあります。 - MIT - Kerberos ウェブサイト - () - に書かれているガイドに従うことが推奨されます。 - path の問題について注意してください。 - MIT port はデフォルトで - /usr/local/ - にインストールします。 - そのため、もし PATH - 環境変数においてシステムのディレクトが最初に書かれている場合には、 - MIT 版ではなく、 - 通常の システムアプリケーションが動いてしまいます。 + &os; が提供する MIT + security/krb5 port において、 + telnetd および klogind + 経由でのログインが奇妙な振る舞いをすることを理解したいのであれば、 + port からインストールされる + /usr/local/share/doc/krb5/README.FreeBSD + ファイルを読んで下さい。 + 最も重要なことは、 + incorrect permissions on cache file + の振る舞いを修正するには、 + フォワードされたクレデンシャリングの所有権を適切に変更できるように、 + login.krb5 + バイナリが認証に使われる必要があります。 - &os; が提供する MIT - security/krb5 port において、 - telnetd および klogind - 経由でのログインが奇妙な振る舞いをすることを理解したいのであれば、 - port からインストールされる - /usr/local/share/doc/krb5/README.FreeBSD - ファイルを読んで下さい。 - 最も重要なことは、 - incorrect permissions on cache file - の振る舞いを修正するには、 - フォワードされたクレデンシャリングの所有権を適切に変更できるように、 - login.krb5 - バイナリが認証に使われる必要があります。 + rc.conf + を以下の設定を含むように変更する必要があります。 - rc.conf - を以下の設定を含むように変更する必要があります。 - - kerberos5_server="/usr/local/sbin/krb5kdc" + kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_enable="YES" kadmind5_server_enable="YES" - これを行うのは、 - MIT kerberos のアプリケーションは、 - /usr/local - 構造の下にインストールされるためです。 - + これを行うのは、 + MIT kerberos のアプリケーションは、 + /usr/local + 構造の下にインストールされるためです。 + - - <application>Kerberos</application> - で見つかった制限を緩和する + + <application>Kerberos</application> + で見つかった制限を緩和する - - Kerberos5 - 制限および欠点 - + + Kerberos5 + 制限および欠点 + - - <application>Kerberos</application> は、all-or-nothing - アプローチです。 + + <application>Kerberos</application> は、all-or-nothing + アプローチです。 - ネットワーク上で有効なすべてのサービスは、 - Kerberos 化 - (または、ネットワーク攻撃に対して安全に) されるべきです。 - さもないと、ユーザのクレデンシャルが盗まれ、 - 利用されることが起きるかもしれません。 - この例は、 - Kerberos 化されたすべてのリモートシェル - (たとえば、rsh および telnet) - です。 - パスワードを平文で送るような - POP3 メールサーバは変換していません。 - + ネットワーク上で有効なすべてのサービスは、 + Kerberos 化 + (または、ネットワーク攻撃に対して安全に) されるべきです。 + さもないと、ユーザのクレデンシャルが盗まれ、 + 利用されることが起きるかもしれません。 + この例は、 + Kerberos 化されたすべてのリモートシェル + (たとえば、rsh および telnet) + です。 + パスワードを平文で送るような + POP3 メールサーバは変換していません。 + - - <application>Kerberos</application> は、 - シングルユーザのワークステーションでの使用を想定しています。 + + <application>Kerberos</application> は、 + シングルユーザのワークステーションでの使用を想定しています。 - マルチユーザの環境では、 - Kerberos は安全ではありません。 - チケットは /tmp - ディレクトリに保管され、 - このチケットは、すべてのユーザが読むことができるためです。 - もし、ユーザがコンピュータを他のユーザと同時に共有 - (i.e. マルチユーザで使用) していると、 - 他のユーザは、そのユーザのチケットを盗む - (コピーする) ことが出来てしまいます。 + マルチユーザの環境では、 + Kerberos は安全ではありません。 + チケットは /tmp + ディレクトリに保管され、 + このチケットは、すべてのユーザが読むことができるためです。 + もし、ユーザがコンピュータを他のユーザと同時に共有 + (i.e. マルチユーザで使用) していると、 + 他のユーザは、そのユーザのチケットを盗む + (コピーする) ことが出来てしまいます。 - この問題は、-c - ファイル名コマンドラインオプションまたは、(好ましくは) - KRB5CCNAME 環境変数によって克服されますが、 - 実際に使われることはまれです。 - 大体においては、チケットをユーザのホームディレクトリに保存し、 - 簡単なファイルの許可属性を設定することで、 - この問題に対応できます。 - + この問題は、-c + ファイル名コマンドラインオプションまたは、(好ましくは) + KRB5CCNAME 環境変数によって克服されますが、 + 実際に使われることはまれです。 + 大体においては、チケットをユーザのホームディレクトリに保存し、 + 簡単なファイルの許可属性を設定することで、 + この問題に対応できます。 + - - KDC は、単一障害点である + + KDC は、単一障害点である - 設計上、KDC は、 - マスターパスワードのデータベースを含むため、 - 安全である必要があります。 - KDC では、 - 絶対に他のサービスを走らせるべきではありませんし、 - 物理的に安全であるべきです。 - Kerberos は、 - KDC 上で、ファイルとして保存されている一つの鍵 - (マスター 鍵) - で暗号化されたすべてのパスワードを保存しているので、 - 非常に危険です。 + 設計上、KDC は、 + マスターパスワードのデータベースを含むため、 + 安全である必要があります。 + KDC では、 + 絶対に他のサービスを走らせるべきではありませんし、 + 物理的に安全であるべきです。 + Kerberos は、 + KDC 上で、ファイルとして保存されている一つの鍵 + (マスター 鍵) + で暗号化されたすべてのパスワードを保存しているので、 + 非常に危険です。 - 追記ですが、マスター鍵が漏洩しても、 - 通常懸念するほど悪いことにはなりません。 - マスター鍵は、Kerberos - データベースの暗号時にのみ、 - 乱数を生成するためのシードとして使われます。 - KDC へのアクセスが安全である限りにおいては、 - マスター鍵を用いて、それほど多くのことはできません。 + 追記ですが、マスター鍵が漏洩しても、 + 通常懸念するほど悪いことにはなりません。 + マスター鍵は、Kerberos + データベースの暗号時にのみ、 + 乱数を生成するためのシードとして使われます。 + KDC へのアクセスが安全である限りにおいては、 + マスター鍵を用いて、それほど多くのことはできません。 - さらに、KDC が - (DoS 攻撃またはネットワーク問題等により) - ネットワークサービスを利用できず、 - 認証ができない場合に対する、DoS 攻撃への対応方法があります。 - この攻撃による被害は、 - 複数の KDC - (ひとつのマスタとひとつまたはそれ以上のスレーブ) - および、セカンダリもしくはフォールバック認証 - (これには、PAM が優れています) - の実装により軽減することができます。 - + さらに、KDC が + (DoS 攻撃またはネットワーク問題等により) + ネットワークサービスを利用できず、 + 認証ができない場合に対する、DoS 攻撃への対応方法があります。 + この攻撃による被害は、 + 複数の KDC + (ひとつのマスタとひとつまたはそれ以上のスレーブ) + および、セカンダリもしくはフォールバック認証 + (これには、PAM が優れています) + の実装により軽減することができます。 + - - <application>Kerberos</application> の欠点 + + <application>Kerberos</application> の欠点 - Kerberos は、 - ユーザ、ホストおよびサービスの間での認証を可能にしますが、 - KDC とユーザ、 - ホストまたはサービスとの間の認証のメカニズムは提供しません。 - これは、(たとえば) トロイの木馬の - kinit が、 - すべてのユーザ名とパスワードを記録できることを意味しています。 - security/tripwire - のような、 - もしくは他のファイルシステムの完全性を確認するためのツールにより、 - この危険性を軽減することができます。 - - + Kerberos は、 + ユーザ、ホストおよびサービスの間での認証を可能にしますが、 + KDC とユーザ、 + ホストまたはサービスとの間の認証のメカニズムは提供しません。 + これは、(たとえば) トロイの木馬の + kinit が、 + すべてのユーザ名とパスワードを記録できることを意味しています。 + security/tripwire + のような、 + もしくは他のファイルシステムの完全性を確認するためのツールにより、 + この危険性を軽減することができます。 + + - - リソースおよび他の情報源 + + リソースおよび他の情報源 - - Kerberos5 - External Resources - + + Kerberos5 + External Resources + - - + + - The Kerberos FAQ + xlink:href="http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html"> + The Kerberos FAQ Designing - an Authentication System: a Dialog in Four Scenes + xlink:href="http://web.mit.edu/Kerberos/www/dialogue.html">Designing + an Authentication System: a Dialog in Four Scenes RFC 1510, - The Kerberos Network Authentication Service - (V5) + xlink:href="http://www.ietf.org/rfc/rfc1510.txt?number=1510">RFC + 1510, The Kerberos Network + Authentication Service (V5) MIT - Kerberos home page + xlink:href="http://web.mit.edu/Kerberos/www/">MIT + Kerberos home + page - Heimdal - Kerberos home page + Heimdal + Kerberos home + page - + @@ -2668,8 +2759,7 @@ kadmind5_server_enable="YES" 最も一般的な OpenSSL の利用方法のひとつは、 ソフトウェアアプリケーションが使えるように証明書を提供することです。 - これらの証明書により、 - 会社または個人の公開鍵が、 + これらの証明書により、会社または個人の公開鍵が、 改ざんやなりすましが行われていないことを確認できます。 もし問題となっている証明書が、認証局 または CA により検証されなければ、 @@ -2747,8 +2837,8 @@ An optional company name []:Another NameRSA の鍵を生成してください。 &prompt.root; openssl dsaparam -rand -genkey -out myRSA.key 1024 - - 次に、CA 鍵を生成してください。 + + 次に、CA 鍵を生成してください。 &prompt.root; openssl gendsa -des3 -out myca.key myRSA.key @@ -2771,8 +2861,7 @@ An optional company name []:Another Name証明書の使用例 これらのファイルで何ができるでしょうか? - 効果的な利用方法は、 - Sendmail + 効果的な利用方法は、Sendmail MTA への接続を暗号化することでしょう。 これにより、 ローカルの MTA 経由でメールを送信するユーザが、 @@ -2805,8 +2894,7 @@ define(`confTLS_SRV_OPTIONS', `V')dnl make install と入力すると再構築できます。 その後、make restart - と入力して、 - Sendmail + と入力して、Sendmail デーモンを再起動してください。 すべてがうまくいっていれば、 @@ -2847,16 +2935,16 @@ Connection closed by foreign host. VPN over IPsec - + - Nik - Clayton + Nik + Clayton
nik@FreeBSD.org
- - 執筆: - + + 執筆: + @@ -2869,9 +2957,10 @@ Connection closed by foreign host. VPN を作成します。 - IPsec を理解する - - + + IPsec を理解する + + Hiten M. Pandya @@ -2889,7 +2978,7 @@ Connection closed by foreign host. IPsec を設定するためには、 カスタムカーネルの構築方法をよく知っている必要があります ( をご覧ください)。 - + IPsec は、インターネットプロトコル (IP) レイヤのトップにあるプロトコルです。 二つもしくはそれ以上のホスト間で安全に通信することを可能にします @@ -2903,7 +2992,7 @@ Connection closed by foreign host. IPsec ESP - + IPsec AH @@ -2912,23 +3001,24 @@ Connection closed by foreign host. IPsec は二つのサブプロトコルから構成されます。 - - Encapsulated Security Payload + + Encapsulated Security Payload (ESP) は、(Blowfish, 3DES のような) 対称暗号アルゴリズムを使ってデータを暗号化することで、 サードパーティのインタフェースから IP パケットデータを保護します。 - - - Authentication Header (AH), + + + + Authentication Header (AH), は、暗号チェックサムを計算し、IP パケットのヘッドフィールドを安全なハッシュ関数でハッシュ化することで、 IP パケットヘッダをサードパーティのインタフェースやなりすましから守ります。 ハッシュを含む追加のヘッダが追加され、 パケット情報の検証が可能になります。 - + - + ESP および AH は、使用する環境に合わせて、 一緒に使うことも別々に使うこともできます。 @@ -2952,7 +3042,7 @@ Connection closed by foreign host. として知られています。 FreeBSD での IPsec サブシステムに関するより詳細な情報については、 &man.ipsec.4; マニュアルページを参照してください。 - + カーネルに IPsec のサポートを追加するには、 カーネルコンフィグレーションファイルに以下のオプションを追加してください。 @@ -2975,18 +3065,17 @@ device crypto 以下のカーネルオプションを追加してください。 -options IPSEC_DEBUG #debug for IP security - +options IPSEC_DEBUG #debug for IP security 問題点 - + VPN の構成についての標準はありません。 VPN は、数多くの技術と共に実装することが可能です。 その各技術には、それ自身の長所と短所があります。 この章では、シナリオを示し、 - そのシナリオに対して、VPN を実装する戦略について説明します。 + そのシナリオに対して、VPN を実装する戦略について説明します。 @@ -3001,31 +3090,35 @@ options IPSEC_DEBUG #debug for IP security 前提は以下の通りです。 - + - - 少なくとも 2 つのサイトを持っています。 - - - どちらのサイトとも内部で IP を使っています。 - - - 2 つのサイトは、FreeBSD で運用されているゲートウェイを通して、 + + 少なくとも 2 つのサイトを持っています。 + + + + どちらのサイトとも内部で IP を使っています。 + + + + 2 つのサイトは、FreeBSD で運用されているゲートウェイを通して、 インターネットに接続しています。 - - - それぞれのネットワークのゲートウェイは、 + + + + それぞれのネットワークのゲートウェイは、 少なくとも一つのパブリック IP アドレスを持っています。 - - - 2 つのネットワークの内部アドレスは、 + + + + 2 つのネットワークの内部アドレスは、 パブリックでもプライベート IP アドレスでも構いません。 IP アドレスは衝突してはいけません。たとえば、両方のネットワークが 192.168.1.x を使ってはいけません。 - + - + &os; 上で IPsec を設定する。 @@ -3060,7 +3153,9 @@ options IPSEC_DEBUG #debug for IP security 実際の内部および外部のゲートウェイのアドレスに置き換えてください。 &prompt.root; ifconfig gif0 create + &prompt.root; ifconfig gif0 internal1 internal2 + &prompt.root; ifconfig gif0 tunnel external1 external2 たとえば、会社の LAN の公開 @@ -3125,15 +3220,17 @@ round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms これは以下のコマンドで設定できます。 &prompt.root; corp-net# route add 10.0.0.0 10.0.0.5 255.255.255.0 + &prompt.root; corp-net# route add net 10.0.0.0: gateway 10.0.0.5 &prompt.root; priv-net# route add 10.246.38.0 10.246.38.1 255.255.255.0 + &prompt.root; priv-net# route add host 10.246.38.0: gateway 10.246.38.1 これで、ネットワーク内のコンピュータは、 ゲートウェイおよびゲートウェイの奥のコンピュータから到達可能となっています。 以下の例で、簡単に確認できます。 - + corp-net# ping 10.0.0.8 PING 10.0.0.8 (10.0.0.8): 56 data bytes 64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms @@ -3239,7 +3336,7 @@ sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $network/ /usr/local/etc/racoon/setkey.conf に保存する必要があります。 -flush; + flush; spdflush; # To the home network spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use; @@ -3323,19 +3420,26 @@ pass out quick on gif0 from any to any ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot racoon_enable="yes" - + - OpenSSH + + OpenSSH - ChernLee寄稿: + + + Chern + Lee + + 寄稿: + - OpenSSH + セキュリティ OpenSSH @@ -3354,7 +3458,8 @@ racoon_enable="yes" OpenSSH は OpenBSD プロジェクトによって維持管理されており、SSH v1.2.12 に最新のすべてのバグ修正と更新を適用したものをベースにしています。 - OpenSSH クライアントは SSH プロトコル 1 と 2 の両方に互換性があります。 + OpenSSH クライアントは + SSH プロトコル 1 と 2 の両方に互換性があります。 OpenSSH を使うことの利点 @@ -3369,6 +3474,7 @@ racoon_enable="yes" sshd を有効にする + OpenSSH 有効化 @@ -3414,10 +3520,11 @@ user@example.com's password: ******* SSH はクライアントが接続した時、 サーバの信頼性の検証のために鍵指紋システム (key fingerprint system) を利用します。 - 初めての接続の際にのみ、ユーザは yes と入力することを要求されます。 + 初めての接続の際にのみ、ユーザは yes + と入力することを要求されます。 これ以降の login では保存されていた鍵指紋を照合することで検証されます。 - SSH クライアントは保存されていた鍵指紋が - login しようとした際に送られてきたものと異なっていた場合には警告を表示します。 + SSH クライアントは保存されていた鍵指紋が login + しようとした際に送られてきたものと異なっていた場合には警告を表示します。 指紋は ~/.ssh/known_hosts に、また SSH v2 指紋の場合は ~/.ssh/known_hosts2 に保存されます。 @@ -3435,11 +3542,14 @@ user@example.com's password: ******* Secure copy + OpenSSH secure copy - scp + + scp + &man.scp.1; コマンドは &man.rcp.1; と同様に働きます。 @@ -3466,6 +3576,7 @@ COPYRIGHT 100% |*****************************| 4735 設定 + OpenSSH 設定 @@ -3529,11 +3640,13 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com 以下の の節で説明されています。 - システムにインストールされている - OpenSSH のバージョンによって、 - オプションやファイルに違いが出てくることがあります。 - &man.ssh-keygen.1; を参照して、 - 問題が起こることを避けてください。 + + システムにインストールされている + OpenSSH のバージョンによって、 + オプションやファイルに違いが出てくることがあります。 + &man.ssh-keygen.1; を参照して、 + 問題が起こることを避けてください。 + @@ -3546,20 +3659,20 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com &man.ssh-agent.1; ユーティリティは、 読み込まれた秘密鍵による認証を取り扱います。 - &man.ssh-agent.1; + &man.ssh-agent.1; は他のアプリケーションの起動に用いられる必要があります。 基本的なレベルではシェルを起動し、 より高度なレベルでは、ウィンドウマネージャも起動します。 シェル上で &man.ssh-agent.1; を使うには、 - まず引数としてシェルを起動する必要があります。 + まず引数としてシェルを起動する必要があります。 次に、&man.ssh-add.1; を実行し、 秘密鍵のパスフレーズを入力することにより、 鍵を追加する必要があります。 一度この過程を終えてしまえば、ユーザは、 対応する公開鍵が置かれているホストに &man.ssh.1; でログインできるようになります。 - 以下はその例です。 + 以下はその例です。 &prompt.user; ssh-agent csh &prompt.user; ssh-add @@ -3571,7 +3684,7 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) &man.ssh-agent.1; への呼び出しが ~/.xinitrc に置かれている必要があります。 これにより、X11 上で起動されるすべてのプログラムにおいて、 - &man.ssh-agent.1; サービスが提供されるようになります。 + &man.ssh-agent.1; サービスが提供されるようになります。 ~/.xinitrc ファイルの例は以下となります。 @@ -3587,18 +3700,19 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) SSH トンネリング + OpenSSH トンネリング - OpenSSH は暗号化されたセッションの中に他のプロトコルを - カプセル化するトンネルを作ることができます。 + OpenSSH + は暗号化されたセッションの中に他のプロトコルをカプセル化するトンネルを作ることができます。 以下のコマンドは &man.ssh.1; で telnet 用のトンネルを作成します。 - &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com + &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com &prompt.user; ssh コマンドは、 @@ -3641,7 +3755,7 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) localport:remotehost:remoteport という形式で指定します。 - + @@ -3660,10 +3774,12 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) この例では、localhost のポート 5023 がリモートマシンの - localhost のポート 23 - に転送されるようになっています。 - 23 は telnet なのでこれは SSH - トンネルを通るセキュアな telnet セッションを作ります。 + localhost のポート + 23 に転送されるようになっています。 + 23 は + telnet なのでこれは SSH + トンネルを通るセキュアな telnet + セッションを作ります。 このようにして SMTP や POP3, FTP 等のセキュアではない TCP プロトコルをカプセル化することができます。 @@ -3698,7 +3814,8 @@ Escape character is '^]'. サーバが動いているメールサーバがあるとします。 ネットワークもしくはあなたの家とオフィスの間のネットワーク経路は、 完全に信頼できるものかもしれませんし、そうではないかもしれません。 - そのため、電子メールは安全なやり方で見るようにしなければなりません。 + そのため、 + 電子メールは安全なやり方で見るようにしなければなりません。 解決策は、オフィスの SSH サーバへの SSH 接続を行い、 メールサーバへのトンネルを作成することです。 @@ -3719,7 +3836,8 @@ user@ssh-server.example.com's password: ****** 外向けの接続もフィルタして、 極端に厳しいファイアウォールルールを課すネットワーク管理者もいます。 リモートのマシンには、SSH 接続と web サーフィンのための - 22 番および 80 番ポートにしか接続させてもらえないかもしれません。 + 22 番および 80 + 番ポートにしか接続させてもらえないかもしれません。 あなたは、それ以外の (もしかすると仕事に関係ない) サービスにアクセスしたくなるかもしれません。 @@ -3737,10 +3855,10 @@ user@ssh-server.example.com's password: ****** &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: ******* - ストリーミングクライアントを localhost - の 8888 番ポートに向けると、music.example.com - の 8000 番ポートに転送され、 - ファイアウォールをすり抜けられます。 + ストリーミングクライアントを + localhost の 8888 番ポートに向けると、 + music.example.com の 8000 + 番ポートに転送され、ファイアウォールをすり抜けられます。 @@ -3749,14 +3867,14 @@ user@unfirewalled-system.example.org's password: *******< <varname>AllowUsers</varname> ユーザオプション ログインできるユーザや接続元を制限することは、 - 通常は良い考えです。 - AllowUsers オプションは、 + 通常は良い考えです。 + AllowUsers オプションは、 この目的のために使うことができます。 - たとえば、 + たとえば、 root ユーザが 192.168.1.32 からのみログインできるようにするには、 - /etc/ssh/sshd_config + /etc/ssh/sshd_config ファイルの設定は以下のようになります。 AllowUsers root@192.168.1.32 @@ -3772,7 +3890,7 @@ user@unfirewalled-system.example.org's password: *******< AllowUsers root@192.168.1.32 admin - 注意すべきことは、 + 注意すべきことは、 このコンピュータにログインする必要のあるすべてのユーザを指定することです。 設定されていないと、そのユーザはログインできなくなります。 @@ -3787,10 +3905,11 @@ user@unfirewalled-system.example.org's password: *******< もっと詳しく知りたい人へ - OpenSSH + OpenSSH &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; - &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5; + &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5; &man.sshd.8; &man.sftp-server.8; &man.sshd.config.5; @@ -3870,21 +3989,23 @@ user@unfirewalled-system.example.org's password: *******< - ACL の動作を変更して、まったく新たに - &man.mount.8; - を行わなくてもフラグを有効にできるようにすることも可能でしょう。 - しかし、我々は、うっかり ACL - を有効にしないでマウントしてしまうのを防ぐようにした方が望ましいと考えました。 - ACL を有効にし、その後無効にしてから、 - 拡張属性を取り消さないでまた有効にしてしまうと、 - 鬱陶しい状態に自分で入り込んでしまえるからです。 - 一般的には、一度ファイルシステムで ACL - を有効にしたら、無効にすべきではありません。そうしてしまうと、 - ファイル保護がシステムのユーザの意図と齟齬をきたす可能性があるばかりか、 - ACL を再度有効にすると、 - それまでパーミッションが変更されてきたファイルに古い - ACL を割り当ててしまい、 - 予想しない動作につながることも考えられます。 + + ACL の動作を変更して、まったく新たに + &man.mount.8; + を行わなくてもフラグを有効にできるようにすることも可能でしょう。 + しかし、我々は、うっかり ACL + を有効にしないでマウントしてしまうのを防ぐようにした方が望ましいと考えました。 + ACL を有効にし、その後無効にしてから、 + 拡張属性を取り消さないでまた有効にしてしまうと、 + 鬱陶しい状態に自分で入り込んでしまえるからです。 + 一般的には、一度ファイルシステムで ACL + を有効にしたら、無効にすべきではありません。そうしてしまうと、 + ファイル保護がシステムのユーザの意図と齟齬をきたす可能性があるばかりか、 + ACL を再度有効にすると、 + それまでパーミッションが変更されてきたファイルに古い + ACL を割り当ててしまい、 + 予想しない動作につながることも考えられます。 + ACL を有効にしたファイルシステムは、 パーミッション設定の表示に + (プラス) @@ -3896,13 +4017,13 @@ drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html - ここでは、ディレクトリ directory1, directory2 および directory3 + ここでは、ディレクトリ + directory1, + directory2 および + directory3 のすべてで ACL が働いています。 - ディレクトリ public_html は対象外です。 + ディレクトリ public_html + は対象外です。 <acronym>ACL</acronym> を利用する @@ -3985,8 +4106,9 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html と呼ばれる追加のユーティリティが、 この目的のために用意されています。 - ports-mgmt/portaudit port は、 - &os; セキュリティチームおよび ports + + ports-mgmt/portaudit + port は、&os; セキュリティチームおよび ports 開発者がアップデートし、管理している、 既知のセキュリティ問題に対するデータベースを入手します。 @@ -4130,7 +4252,8 @@ VII. References - Topic フィールドは、何が問題であるかを正確に示しています。 + Topic フィールドは、 + 何が問題であるかを正確に示しています。 通常は、このセキュリティ勧告の導入部であり、 脆弱性のあるユーティリティを示します。 @@ -4171,7 +4294,7 @@ VII. References - Credits フィールドは、 + Credits フィールドは、 脆弱性を通知し、報告した個人または組織を示します。 @@ -4334,5 +4457,5 @@ VII. References &man.lastcomm.1;, &man.acct.5; および &man.sa.8; マニュアルページで 説明されています。 - +