From owner-svn-doc-all@freebsd.org Sun Jan 8 14:00:28 2017 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 035BECA5CEF; Sun, 8 Jan 2017 14:00:28 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8936E1007; Sun, 8 Jan 2017 14:00:27 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id v08E0QcO004078; Sun, 8 Jan 2017 14:00:26 GMT (envelope-from ryusuke@FreeBSD.org) Received: (from ryusuke@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id v08E0Qbn004077; Sun, 8 Jan 2017 14:00:26 GMT (envelope-from ryusuke@FreeBSD.org) Message-Id: <201701081400.v08E0Qbn004077@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ryusuke set sender to ryusuke@FreeBSD.org using -f From: Ryusuke SUZUKI Date: Sun, 8 Jan 2017 14:00:26 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r49804 - head/ja_JP.eucJP/books/handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 14:00:28 -0000 Author: ryusuke Date: Sun Jan 8 14:00:26 2017 New Revision: 49804 URL: https://svnweb.freebsd.org/changeset/doc/49804 Log: - Merge the following from the English version: r18074 -> r18103 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 Sun Jan 8 13:02:26 2017 (r49803) +++ head/ja_JP.eucJP/books/handbook/security/chapter.xml Sun Jan 8 14:00:26 2017 (r49804) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r18074 + Original revision: r18103 $FreeBSD$ --> @@ -24,7 +24,7 @@ この章では、基本的なシステムセキュリティの考え方、 覚えておくべき一般的なルールを紹介し、 - FreeBSD における高度な話題について簡単に説明します + &os; における高度な話題について簡単に説明します ここで扱う話題の多くは、 一般的なシステムやインターネットセキュリティにもあてはまります。 インターネットはもはや、誰もが親切な隣人であろうとする @@ -40,13 +40,13 @@ - FreeBSD + &os; に関する基本的なシステムセキュリティの考え方 - DES や MD5 のような、FreeBSD - で利用できるさまざまな暗号化手法について + DES や MD5 のような、 + &os; で利用できるさまざまな暗号化手法について @@ -54,26 +54,32 @@ - もう一つの代替認証システム Kerberos の設定方法 + &os; 5.0 より前のリリースにおける、 + KerberosIV の設定方法 - IPFW で firewall を構築する方法 + &os; 5.0 以降のリリースにおける、 + Kerberos5 の設定方法 - IPsec および FreeBSD/&windows; コンピュータの間で VPN - の設定方法 + IPFW でファイアウォールを構築する方法 - FreeBSD で使われている SSH 実装である + IPsec および FreeBSD/&windows; コンピュータの間で + VPN の設定方法 + + + + &os; で使われている SSH である OpenSSH の設定および使用方法 @@ -87,7 +93,7 @@ - FreeBSD およびインターネットの基本概念の理解 + &os; およびインターネットの基本概念の理解 @@ -461,7 +467,7 @@ ステーションやサーバへの物理的アクセス手段を持たない人々によっ て行われるという事実もまた、念頭に置いておく必要があります。 - Kerberos + KerberosIV Kerberos のような方法を使うことで、 スタッフアカウントのパ @@ -1001,7 +1007,7 @@ Kerberos および SSH を用いたアクセスの問題 ssh - Kerberos + KerberosIV もしあなたが、Kerberos と ssh を使いたいのだとしたら、 両者に関して言っておかねばならない問題がいくつかあります。 @@ -1603,8 +1609,8 @@ permit port ttyd0 - - Kerberos + + KerberosIV MarkMurray寄稿: @@ -1633,14 +1639,14 @@ permit port ttyd0 でしょう。 - Kerberos のインストール + KerberosIV のインストール MIT - Kerberos + KerberosIV インストール - Kerberos は選択が任意な FreeBSD のコンポーネントです。 + Kerberos は選択が任意な &os; のコンポーネントです。 もっとも簡単なインストール方法は、FreeBSD のインストール時に sysinstall で krb4 または krb5 @@ -1766,6 +1772,11 @@ Master key entered. BEWARE! すべてが動くようにするための設定 + + KerberosIV + 初期設定 + + Kerberosを導入する それぞれの システムのデータベースに、2つ のprincipal (主体名) を追加する必要があります。その名前は @@ -1992,7 +2003,7 @@ Password changed. というインスタンスに よって制御されています。 kdb_editを用いて jane.rootというエントリを - Kerberosデータベースに作成します。 + Kerberos データベースに作成します。 &prompt.root; kdb_edit Opening database... @@ -2123,6 +2134,896 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat A + + <application>Kerberos5</application> + + + + Tillman + Hodgson + + 寄稿: + + + + + + Mark + Murray + + 基にした文書の執筆: + + + + + &os;-5.1 リリース以降のすべての &os; には、 + Kerberos5 のみが含まれています。 + Kerberos5 + はインストールされている唯一のバージョンであり、設定は、多くの側面で + KerberosIV と似ています。 + 以下の情報は、&os;-5.0 リリース以降の + Kerberos5 のみに適応が可能です。 + KerberosIV package + を使いたいと考えているユーザは、 + security/krb4 port + をインストールしてください。 + + Kerberos は、 + サーバのサービスによってユーザが安全に認証を受けられるようにするための、 + ネットワークの付加システムおよびプロトコルです。 + リモートログイン、リモートコピー、 + システム間でのファイルのコピーおよび他のリスクの高いタスクをかなり安全に、 + そしてこれまでより制御できるようになります。 + + Kerberos は、 + 身元確認プロキシシステムや、 + 信頼される第 3 者認証システムとも説明されます。 + Kerberos は、一つの機能 — + ネットワーク上のユーザの安全な認証 — + だけを提供します。 + 承認 (どのユーザが許可されているか) + や監査 (ユーザがどのような作業を行っているか) + の機能は提供しません。 + Kerberos を使って、 + クライアントおよびサーバの身元を証明した後は、 + 日常業務におけるすべての通信を暗号化して、 + プライバシおよびデータの完全性を保証することができます。 + + そのため、Kerberos を使う際は、 + 承認および監査サービスを提供する他のセキュリティの手段との利用が、 + 強く推奨されます。 + + 以下の文章は、&os; 用として配布されている + Kerberos + をセットアップする際のガイドとして利用できますが、 + 完全な説明が必要な場合には、 + マニュアルページを参照してください。 + + この節における Kerberos + のインストールのデモでは、以下のような名前空間が使われます。 + + + + DNS ドメイン (ゾーン) は、 + EXAMPLE.ORG です。 + + + + Kerberos の領域は、 + EXAMPLE.ORG です。 + + + + + Kerberos の設定では、 + 内部での使用でも実際のドメイン名を使ってください。 + DNS の問題を避けることができ、 + 他の Kerberos のレルム (realm) + との相互運用を保証します。 + + + + 歴史 + + Kerberos5 + 歴史 + + + Kerberos は、 + ネットワークのセキュリティ問題を解決するために、 + MIT で開発されました。 + Kerberos プロトコルは、 + 必ずしも安全ではないインターネット接続においても、 + サーバに対して (逆もまた同様に)、 + 強い暗号を使って身元を証明します。 + + Kerberos は、 + ネットワーク認証プロトコルの名前であり、 + このプログラムを実装しているプログラムを表す + (例 Kerberos telnet) + ための形容詞でもあります。 + プロトコルの現在のバージョンはバージョン 5 で、 + RFC 1510 として文書化されています。 + + このプロトコルのいくつものフリーの実装が、 + さまざまなオペレーティングシステムで利用できます。 + 最初の Kerberos + を開発したマサチューセッツ工科大学 (MIT) は、 + 開発した Kerberos + パッケージを継続的に保守しています。 + アメリカ合衆国では暗号製品として良く使われていますが、 + 歴史的には、 + アメリカ合衆国 の輸出規制により制限されてきました。 + MIT で実装された + Kerberos は、port + (security/krb5) + から利用できます。 + バージョン 5 のもう一つの実装が、 + Heimdal Kerberos + です。 + この実装は、アメリカ合衆国の外で開発されたため、 + 輸出の制限を避けることができます + (そのため、非商用の &unix;-like なシステムによく含まれています)。 + Heimdal Kerberos は port + (security/heimdal) + からインストールできますが、最小構成は + &os; の base インストールに含まれています。 + + 幅広い読者を対象とするために、以下の説明では + &os; に含まれている Heimdal + ディストリビューションの使用を想定しています。 + + + + Heimdal <acronym>KDC</acronym> の設定 + + Kerberos5 + 鍵配布センターの設定 + + + 鍵配布センター (KDC) は、 + Kerberos + が提供する中心的な認証サービス + — Kerberos + チケットを発行するコンピュータです。 + KDC は、 + Kerberos + のレルムの中のすべてのコンピュータから + 信頼されています。 + そのため、厳重なセキュリティに対する配慮が必要となります。 + + Kerberos + サーバの実行にコンピュータのリソースは必要ありませんが、 + セキュリティの観点から、KDC + としてのみ機能する専用のコンピュータが推奨されます。 + + KDC を設定するにあたって、 + KDC として動作するために、 + 適切に /etc/rc.conf が設定されていること + (システムを反映するようにパスを調整する必要があります) + を確認してください。 + + kerberos5_server_enable="YES" +kadmind5_server_enable="YES" +kerberos_stash="YES" + + + は、 + &os; 4.X でのみ利用可能です。 + + + 次に、Kerberos + の設定ファイル /etc/krb5.conf + を編集します。 + + [libdefaults] + default_realm = EXAMPLE.ORG +[realms] + EXAMPLE.ORG = { + kdc = kerberos.EXAMPLE.ORG + } +[domain_realm] + .EXAMPLE.ORG = EXAMPLE.ORG + + /etc/krb5.conf ファイルの中では、 + KDC は、 + 完全修飾されたホスト名 + kerberos.EXAMPLE.ORG + を持つことが想定されていることに注意してください。 + KDC が異なるホスト名である場合には、 + 名前の解決が行われるように、適切に CNAME (エイリアス) + エントリをゾーンファイルに追加する必要があります。 + + + 適切に BIND DNS + サーバが設定されたネットワークでは、 + 上記の例は、以下のように整理されます。 + + [libdefaults] + default_realm = example.org + + そして、kerberos.EXAMPLE.ORG + ゾーンファイルには、以下の行が付け加えられます。 + + _kerberos._udp IN SRV 01 00 88 kerberos.example.org. +_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 データベースを作成します。 + このデータベースには、 + マスター鍵により暗号化されたすべてのプリンシパルの鍵があります。 + このパスワードは、ファイル + (/var/heimdal/m-key) に保存されるため、 + 覚える必要はありません。 + マスター鍵を作成するには、kstash を実行して、 + パスワードを入力してください。 + + マスター鍵を作成したら、kadmin プログラムを + -l オプション (local を意味します) + で実行し、初期化します。 + このオプションを使うと、kadmin は、 + kadmind ネットワークサービスを使わず、 + 直接データベースファイルを変更します。 + これにより、 + データベースを作成する前に、データベースへの接続を試みてしまうという、 + 卵が先か鶏が先かという問題を回避できます。 + kadmin + プロンプトが表示されたら、init コマンドを使って、 + レルムに関する初期のデータベースを作成してください。 + + 最後に、kadmin プロンプトで + add + コマンドを使って最初のプリンシパルを作成して下さい。 + 差し当たりは、 + プリンシパルに対するデフォルトのオプションに従ってください。 + 後で modify コマンドを使うことで、 + いつでも変更することができます。 + プロンプトで ? コマンドを使うと、 + 利用可能なオプションを確認できます。 + + データベース作成のセッションの例は以下のようになります。 + + &prompt.root; kstash + Master key: xxxxxxxx + Verifying password - Master key: xxxxxxxx + + &prompt.root; kadmin -l + kadmin> init EXAMPLE.ORG + Realm max ticket life [unlimited]: + kadmin> add tillman + Max ticket life [unlimited]: + Max renewable life [unlimited]: + Attributes []: + Password: xxxxxxxx + Verifying password - Password: xxxxxxxx + + これで KDC + サービスを起動することができるようになりました。 + /etc/rc.d/kerberos start および + /etc/rc.d/kadmind start + を実行してサービスを起動してください。 + この時点で、kerberos 化されたデーモンが走っていなくても、 + KDC のコマンドラインから、作成したばかりの (ユーザ) + プリンシパルのチケットを入手したり、 + 一覧を表示することができることを確認してください。 + + &prompt.user;k5init tillman + tillman@EXAMPLE.ORG's Password: + + &prompt.user;k5list + Credentials cache: FILE:/tmp/krb5cc_500 + Principal: tillman@EXAMPLE.ORG + + Issued Expires Principal + Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG + Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG + + v4-ticket file: /tmp/tkt500 + k5list: No ticket file (tf_util) + + + + + Heimdal <application>Kerberos</application> + サービスを有効にする。 + + + Kerberos5 + Enabling サービス + + + 最初に Kerberos + の設定ファイル /etc/krb5.conf + のコピーが必要です。 + コピーを行うには、KDC から、 + クライアントコンピュータへ + (&man.scp.1; のようなネットワークユーティリティを使うか、 + 物理的にフロッピーディスクを使って) + 安全な方法でコピーをしてください。 + + 次に /etc/krb5.keytab + ファイルが必要となります。 + これは、Kerberos + 化されたデーモンを提供するサーバとワークステーションの間での大きな違いです + — サーバは、 + keytab ファイルを持っている必要があります。 + このファイルには、サーバのホスト鍵が含まれています。 + この鍵により、ホストおよび + KDC が他の身元の検証ができます。 + 鍵が公開されてしまうと、 + サーバのセキュリティが破れてしまうため、 + このファイルは安全にサーバに転送しなければなりません。 + このことは、FTP + のようにテキストチャネルでの転送は、 + まったく好ましくないことを意味しています。 + + 一般的には、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 を使用して、 + ローカルで管理作業を行ってください。 + + /etc/krb5.conf + ファイルをインストールしたら、 + Kerberos サーバから、 + kadmin を使うことができます。 + add --random-key コマンドを使うと、 + サーバのホストプリンシパルを追加できます。 + そして、ext コマンドを用いて、 + サーバのホストプリンシパルを keytab に抽出してください。 + + &prompt.root; kadmin + kadmin> add --random-key host/myserver.EXAMPLE.ORG + Max ticket life [unlimited]: + Max renewable life [unlimited]: + Attributes []: + kadmin> ext host/myserver.EXAMPLE.ORG + kadmin> exit + + ext コマンド (extract + の省略形) は、デフォルトでは、抽出された鍵を + /etc/krb5.keytab に保存します。 + + KDC 上で kadmind + を (おそらくセキュリティ上の理由から) 走らせていない場合で、 + リモートから kadmin に接続出来ない場合には、 + ホストプリンシパル (host/myserver.EXAMPLE.ORG) + を直接 KDC 上で追加し、 + その後、以下のように + (KDC 上の + /etc/krb5.keytab の上書きを避けるため)、 + 一時ファイルに抽出してください。 + + &prompt.root; kadmin + kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org + kadmin> exit + + その後、keytab を安全に (たとえば + scp またはフロッピーを使って) + サーバコンピュータにコピーしてください。 + KDC 上の keytab を上書きすることを避けるため、 + デフォルトとは異なる名前を指定してください。 + + これでサーバは、 + (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 + + 重要な箇所は、ユーザに -a + (認証を表す) が設定されていることです。 + 詳細については、 + &man.telnetd.8; マニュアルページを参照してください。 + + + + Heimdal <application>Kerberos</application> + クライアントを有効にする + + + Kerberos5 + クライアントの設定 + + + クライアントコンピュータの設定は、 + ほとんど取るに足らないくらいに簡単です。 + Kerberos の設定がうまくいっていれば、 + /etc/krb5.conf に置かれている + Kerberos + の設定ファイルのみが必要です。 + セキュリティ的に安全な方法で、KDC + からクライアントコンピュータへ単にコピーしてください。 + + クライアントから、kinit, + klist および + kdestroy を使用し、 + 上記で作成したプリンシパルに対するチケットの入手、表示、 + 削除を行い、クライアントコンピュータを試験してください。 + Kerberos + アプリケーションを使って Kerberos + が有効なサーバに接続することもできるはずです。 + もしうまく機能しない場合でも、チケットを入手できるのであれば、 + 問題はおそらくサーバにあり、 + クライアントまたは KDC + の問題ではないと考えられます。 + + telnet + のようなアプリケーションを試験する際には、 + (&man.tcpdump.1; といった) パケットスニファを使用して、 + パスワードが平文で送られていないことを確認してください。 + -x オプションで + telnet を利用すると、 + (ssh のように) + すべてのデータストリームが暗号化されます。 + + Kerberos + のコアのクライアントアプリケーション + (伝統的に、kinit, + klist, kdestroy および + kpasswd という名前です) は、&os; + のベースにインストールされています。 + 5.0 以前の &os; では、 + k5init, + k5list, k5destroy, + k5passwd および kstash + と言う名前でインストールされています。 + これらは通常一度しか用いられません。 + + デフォルトでは、Heimdal インストールの + 最小 と考えられる、コア以外の + Kerberos + クライアントアプリケーションもインストールされます。 + telnet は、 + Kerberos + 化された唯一のサービスです。 + + Heimdal port は、 + Kerberos 化されている + ftp, rsh, + rcp, rlogin + および他のあまり一般的ではないプログラムといった、 + インストールされていないクライアントアプリケーションをインストールします。 + MIT port も、すべての + Kerberos + クライアントアプリケーションをインストールします。 + + + + ユーザ設定ファイル: <filename>.k5login</filename> + および <filename>.k5users</filename> + + + Kerberos5 + ユーザ設定ファイル + + + レルムのユーザは、一般的には、 + (tillman + のような) ローカルユーザアカウントに対応する + (tillman@EXAMPLE.ORG + といった) Kerberos + プリンシパルを持ちます。 + telnet + のようなクライアントアプリケーションは、 + ユーザ名もしくはプリンシパルを通常必要としません。 + + しかしながら、時々 + Kerberos + プリンシパルに対応しないローカルユーザアカウントへのアクセスが必要となることがあります。 + たとえば、 + tillman@EXAMPLE.ORG + が、ローカルユーザアカウント + webdevelopers + へのアクセスが必要となることがあります。 + そして、他のプリンシパルが同じローカルアカウントにアクセスが必要になることもあります。 + + ユーザのホームディレクトリに置かれた + .k5login および + .k5users ファイルによって + (.hosts および .rhosts + の強力な組み合わせのように)、この問題を解決出来ます。 + たとえば、以下の行を含む + .k5login を + + tillman@example.org + jdoe@example.org + + ローカルユーザ + webdevelopers + のホームディレクトリに置くと、 + 一覧にある両方のプリンシパルは、 + 共有のパスワードを必要としなくても、 + このアカウントにアクセス出来ます。 + + これらのコマンドのマニュアルページを読むことが推奨されます。 + ksu マニュアルページには、 + .k5users の説明があります。 + + + + <application>Kerberos</application> Tips, Tricks, およびトラブルシューティング + + + Kerberos5 + トラブルシューティング + + + + + Heimdal または MIT + Kerberos ports + のどちらを使う場合でも、 + PATH 環境変数は、 + Kerberos 版のクライアント + アプリケーションが、 + システムにあるアプリケーションより先に見つかるように設定されていることを確認してください。 + + + + システムの時刻は同期していますか? 本当ですか? + 時刻が同期していないと + (通常は 5 分以内で同期されていないと) + 認証に失敗してしまいます。 + + + + MIT および Heimdal 間の運用は、 + 標準化されていないプロトコル kadmin を除き、 + うまく機能します。 + + + + ホスト名を変更する際は、 + 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. + + + + KDC + に対しクライアントとして振る舞うオペレーティングシステムの中には、 + ksu に対して、 + root 権限に + setuid を許可しないものがあります。 + この設定では、 + ksu は動作しないことを意味します。 + セキュリティの観点からは好ましい考えですが、 + 厄介です。これは + KDC のエラーではありません。 + + + + 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 + の真偽の検証を可能にしている部分です。 + + + + レルムにあるすべてのコンピュータの間で時刻が同期している必要があります。 + この目的に完璧に適しているのが、 + NTP です。 + NTP の詳細については、 + をご覧ください。 + + + + (たとえば一週間といった) + 長い有効期限のチケットを使いたい場合で、 + OpenSSH を使って、 + チケットが保存されているコンピュータに接続しようとする場合は、 + Kerberos + が + sshd_config において + no と設定されているか、 + チケットが、ログアウト時に削除されることを確認してください。 + + + + ホストプリンシパルも長い有効期限のチケットを持てることを覚えておいてください。 + もし、ユーザプリンシパルが 1 週間の有効期限を持ち、 + 接続しているホストが、9 時間の有効期限を持っている場合には、 + キャッシュのホストプリンシパル (の鍵) の有効期限が切れてしまい、 + 想定したように、チケットキャッシュが振る舞わないことが起こりえます。 + + + + 特定の問題のあるパスワードが使われることを避けるために + (kadmind のマニュアルページでは、 + この点について簡単に触れています)、 + krb5.dict ファイルを設定する時には、 + パスワードポリシが割り当てられたプリンシパルにのみ適用されることに注意してください。 + krb5.dict ファイルの形式は簡単です。 + : 一行に一つの文字列が置かれています。 + /usr/share/dict/words + にシンボリックリンクを作成することは、有効です。 + + + + + + + <acronym>MIT</acronym> port との違いについて + + MIT + とインストールされている Heimdal 版の大きな違いは、 + kadmin に関連しています。 + このプログラムは、異なる (ただし等価な) コマンド群を持ち、そして、 + 異なるプロトコルを使用します。 + もし KDC に MIT + を使用している場合には、 + Heimdal kadmin + プログラムを使って KDC をリモートから + (この場合は、逆も同様に) 管理できない + ことを意味しています。 + + クライアントアプリケーションでは、同じタスクを行う際に、 + 若干異なるコマンドラインのオプションが必要となることもあります。 + 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 + バイナリが認証に使われる必要があります。 + + + + <application>Kerberos</application> + で見つかった制限を緩和する + + + Kerberos5 + 制限および欠点 + + + + <application>Kerberos</application> は、all-or-nothing + アプローチです。 + + ネットワーク上で有効なすべてのサービスは、 + Kerberos 化 + (または、ネットワーク攻撃に対して安全に) されるべきです。 + さもないと、ユーザのクレデンシャルが盗まれ、 + 利用されることが起きるかもしれません。 + この例は、 + Kerberos 化されたすべてのリモートシェル + (たとえば、rsh および telnet) + です。 + パスワードを平文で送るような + POP3 メールサーバは変換していません。 + + + + <application>Kerberos</application> は、 + シングルユーザのワークステーションでの使用を想定しています。 + + マルチユーザの環境では、 + Kerberos は安全ではありません。 + チケットは /tmp ディレクトリに保管され、 + このチケットは、すべてのユーザが読むことができるためです。 + もし、ユーザがコンピュータを他のユーザと同時に共有 + (i.e. マルチユーザで使用) していると、 + 他のユーザは、そのユーザのチケットを盗む + (コピーする) ことが出来てしまいます。 + + この問題は、-c + ファイル名コマンドラインオプションまたは、(好ましくは) + KRB5CCNAME 環境変数によって克服されますが、 + 実際に使われることはまれです。 + 大体においては、チケットをユーザのホームディレクトリに保存し、 + 簡単なファイルの許可属性を設定することで、 + この問題に対応できます。 + + + + KDC は、単一障害点である + + 設計上、KDC は、 + マスターパスワードのデータベースを含むため、 + 安全である必要があります。 + KDC では、 + 絶対に他のサービスを走らせるべきではありませんし、 + 物理的に安全であるべきです。 + Kerberos は、 + KDC 上で、ファイルとして保存されている一つの鍵 + (マスター 鍵) + で暗号化されたすべてのパスワードを保存しているので、 + 非常に危険です。 + + 追記ですが、マスター鍵が漏洩しても、 + 通常懸念するほど悪いことにはなりません。 + マスター鍵は、Kerberos + データベースの暗号時にのみ、 + 乱数を生成するためのシードとして使われます。 + KDC へのアクセスが安全である限りにおいては、 + マスター鍵を用いて、それほど多くのことはできません。 + + さらに、KDC が + (DoS 攻撃またはネットワーク問題等により) + ネットワークサービスを利用できず、 + 認証ができない場合に対する、DoS 攻撃への対応方法があります。 + この攻撃による被害は、 + 複数の KDC + (ひとつのマスタとひとつまたはそれ以上のスレーブ) + および、セカンダリもしくはフォールバック認証 + (これには、PAM が優れています) + の実装により軽減することができます。 + + + + <application>Kerberos</application> の欠点 + + Kerberos は、 + ユーザ、ホストおよびサービスの間での認証を可能にしますが、 + KDC とユーザ、 + ホストまたはサービスとの間の認証のメカニズムは提供しません。 + これは、(たとえば) トロイの木馬の + kinit が、 + すべてのユーザ名とパスワードを記録できることを意味しています。 + security/tripwire + のような、 + もしくは他のファイルシステムの完全性を確認するためのツールにより、 *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***