14.5. Kerberos5
戻る〓 | 第14章 セキュリティ | 〓次へ

## 14.5. Kerberos5

寄稿: Hodgson Tillman [FAMILY Given].
基にした文書の執筆: Murray Mark [FAMILY Given].

Kerberos は、 サーバのサービスによってユーザが安全に認証を受けられるようにするための、 ネットワークの付加システムおよびプロトコルです。 Kerberos は、 身元確認プロキシシステムや、 信頼される第 3 者認証システムとも説明されます。 ユーザが Kerberos を使って認証を行った後は、 通信は暗号化され、 プライバシおよびデータの完全性を保証することができます。

Kerberos の唯一の機能は、 ネットワーク上のユーザの安全な認証を提供することです。 承認 (どのユーザが許可されているか) や監査 (ユーザがどのような作業を行っているか) の機能は提供しません。 Kerberos を使う際は、 承認および監査サービスを提供する他のセキュリティの手段との利用が、 推奨されます。

この節では、FreeBSD 用として配布されている Kerberos をセットアップする際のガイドを提供します。 完全な説明が必要な場合には、 マニュアルページを参照してください。

この節における Kerberos のインストールのデモでは、以下のような名前空間が使われます。

- DNS ドメイン (「ゾーン」) は、 `example.org` です。

- Kerberos の領域は、 `EXAMPLE.ORG` です。

### 注記:

Kerberos の設定では、 内部での使用でも実際のドメイン名を使ってください。 DNS の問題を避けることができ、 他の Kerberos のレルム (realm) との相互運用を保証します。

### 14.5.1. 歴史

Kerberos は、 ネットワークのセキュリティ問題を解決するために、 MIT で開発されました。 Kerberos プロトコルは、 必ずしも安全ではないインターネット接続においても、 サーバに対して (逆もまた同様に)、 強い暗号を使って身元を証明します。

Kerberos は、 ネットワーク認証プロトコルの名前であり、 Kerberos telnet のように、 このプログラムを実装しているプログラムを表すための形容詞でもあります。 プロトコルの現在のバージョンはバージョン 5 で、 RFC 1510 として文書化されています。

このプロトコルのいくつものフリーの実装が、 さまざまなオペレーティングシステムで利用できます。 最初の Kerberos を開発したマサチューセッツ工科大学 (MIT) は、 開発した Kerberos パッケージを継続的に保守しています。 アメリカ合衆国では暗号製品として良く使われていますが、 歴史的には、 アメリカ合衆国 の輸出規制により制限されてきました。 MIT で実装された Kerberos は、 security/krb5 package または port から利用できます。 バージョン 5 のもう一つの実装が、 Heimdal Kerberos です。 この実装は、アメリカ合衆国の外で開発されたため、 輸出の制限を避けることができます。 Heimdal Kerberos は security/heimdal> package または port からインストールできますが、最小構成は FreeBSD の base インストールに含まれています。

以下の説明では FreeBSD に含まれている Heimdal ディストリビューションの使用を想定しています。

### 14.5.2. Heimdal KDC の設定

鍵配布センター (KDC) は、 Kerberos が提供する中心的な認証サービスで、 Kerberos チケットを発行するコンピュータです。 KDC は、 Kerberos のレルムの中のすべてのコンピュータから 「信頼」されています。 そのため、厳重なセキュリティに対する配慮が必要となります。

Kerberos サーバの実行にコンピュータのリソースはほとんど必要ありませんが、 セキュリティの観点から、KDC としてのみ機能する専用のコンピュータが推奨されます。

KDC を設定するにあたって、 KDC として動作するために、 適切に `/etc/rc.conf` が設定されていることを確認してください。 必要に応じて、 システムの設定を反映するようにパスを調整する必要があります。

    kerberos5_server_enable="YES"
    kadmind5_server_enable="YES"

次に、`/etc/krb5.conf` を以下のように編集してください。

    [libdefaults]
        default_realm = EXAMPLE.ORG
    [realms]
        EXAMPLE.ORG = {
            kdc = kerberos.example.org
            admin_server = kerberos.example.org
        }
    [domain_realm]
        .example.org = EXAMPLE.ORG

`/etc/krb5.conf` の中で、 KDC は、 完全修飾されたホスト名 `kerberos.example.org` を使うことが想定されています。 KDC が異なるホスト名を持つ場合には、 名前の解決が行われるように、適切に CNAME (エイリアス) エントリをゾーンファイルに追加してください。

### 注記:

適切に DNS サーバが設定されている大きなネットワークでは、 上記の例は、以下のように整理されます。

    [libdefaults]
          default_realm = EXAMPLE.ORG

そして、`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 サービスを見つけるためには、 `/etc/krb5.conf` を完全に設定するか、 `/etc/krb5.conf` を最低限に設定し、 さらに DNS サーバを適切に設定する 必要 があります。

次に Kerberos データベースを作成してください。 このデータベースには、 マスター鍵により暗号化されたすべてのプリンシパルの鍵が含まれています。 このパスワードは、 `/var/heimdal/m-key` に保存されるため、 覚える必要はありません。 マスター鍵を作成するには、kstash(8) を実行して、 パスワードを入力してください。

マスター鍵を作成したら、`kadmin -l` を使ってデータベースを初期化してください。 このオプションを使うと、kadmin(8) は、 kadmind(8) ネットワークサービスを使わず、 ローカルのデータベースファイルを直接変更します。 これにより、 データベースを作成する前に、データベースへの接続を試みてしまうという、 卵が先か鶏が先かという問題を回避できます。 kadmin(8) プロンプトで、 `init` を使って、 レルムに関する初期のデータベースを作成してください。

最後に、kadmin(8) プロンプトで `add` を使って最初のプリンシパルを作成して下さい。 差し当たりは、 プリンシパルに対するデフォルトのオプションに従ってください。 後で `modify` を使うことで、 変更することができます。 kadmin(8) プロンプトで `?` と入力すると、 利用可能なオプションを確認できます。

データベース作成のセッションの例は以下のようになります。

    # kstash
    Master key: xxxxxxxx
    Verifying password - Master key: xxxxxxxx

    # 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 サービスを起動してください。 `service kerberos start` および `service kadmind start` を実行してサービスを起動してください。 この時点で、kerberos 化されたデーモンが走っていなくても、 KDC のコマンドラインから、作成したばかりの (ユーザ) プリンシパルのチケットを入手したり、 一覧を表示することができることを確認できます。

    % kinit tillman
    tillman@EXAMPLE.ORG's Password:

    % klist
    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

必要がなくなった時には、チケットを破棄できます。

    % kdestroy

### 14.5.3. Heimdal Kerberos サービスを有効にする。

最初に `/etc/krb5.conf` を KDC からクライアントコンピュータへ、 scp(1) または物理的にリムーバブルディスクを使うといった安全な方法でコピーしてください。

次に `/etc/krb5.keytab` を作成してください。 これが Kerberos 化されたデーモンを提供するサーバとワークステーションの間での大きな違いです: サーバには `keytab` が置かれている必要があります。 このファイルには、サーバのホスト鍵が含まれています。 この鍵により、ホストおよび KDC が他の身元の検証ができます。 鍵が公開されてしまうと、 サーバのセキュリティが破られてしまうため、 このファイルは安全にサーバに転送しなければなりません。

一般的には、kadmin(8) を使って、 `keytab` をサーバに転送します。 ホストプリンシパル (KDC 側の `krb5.keytab`) も kadmin(8) を使って作成するので便利です。

すでにチケットを入手し、そのチケットは、 kadmin(8) インタフェースで使用できることが `kadmind.acl` で許可されている必要があります。 アクセスコントロールリストの設計の詳細については、 `info heimdal` の 「Remote administration」 というタイトルの章をご覧ください。 リモートからの `kadmin` アクセスを有効にする代わりに、 管理者は、ローカルコンソールまたは ssh(1) を用いて安全に KDC に接続し、 `kadmin -l` を使用して、 ローカルで管理作業を行うことができます。

`/etc/krb5.conf` をインストールしたら、 Kerberos サーバから `add --random-key` を使ってください。 このコマンドは、サーバのホストプリンシパルを追加します。 そして、`ext` を用いて、 サーバのホストプリンシパルを keytab に抽出してください。 以下は、使用例です。

    # 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` は、デフォルトでは、抽出された鍵を `/etc/krb5.keytab` に保存します。

KDC 上で kadmind(8) を走らせていない場合で、 リモートから kadmin(8) に接続出来ない場合には、 ホストプリンシパル (`host/myserver.EXAMPLE.ORG`) を直接 KDC 上で追加し、 その後、以下のように KDC 上の `/etc/krb5.keytab` の上書きを避けるため、 一時ファイルに抽出してください。

    # kadmin
    kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org
    kadmin> exit

その後、scp(1) またはリムーバブルディスクを使って、 keytab を安全にサーバコンピュータにコピーしてください。 KDC 上の keytab を上書きすることを避けるため、 デフォルトとは異なる名前を指定してください。

これでサーバは、 `krb5.conf` を使って KDC と通信ができるようになりました。 そして、`krb5.keytab` によって身元を証明できるようになったので、 Kerberos サービスを有効にする準備が出来ました。 この例では、 telnetd(8) サービスが `/etc/inetd.conf` で有効に設定され、 `service inetd restart` によって、 inetd(8) サービスを再起動します。

    telnet    stream  tcp     nowait  root    /usr/libexec/telnetd  telnetd -a user

重要な変更箇所は、`-a` 認証がユーザに設定されていることです。 詳細については、 telnetd(8) を参照してください。

### 14.5.4. Heimdal Kerberos クライアントを有効にする

クライアントコンピュータの設定は簡単です。 `/etc/krb5.conf` のみが必要です。 このファイルをセキュリティ的に安全な方法で、KDC からクライアントコンピュータへコピーしてください。

クライアントから、kinit(1), klist(1) および kdestroy(1) を使用し、 上記で作成したプリンシパルに対するチケットの入手、表示、 削除を行い、クライアントコンピュータを試験してください。 Kerberos アプリケーションを使って Kerberos が有効なサーバに接続することもできるはずです。 もしうまく機能しない場合でも、チケットを入手できるのであれば、 問題はおそらくサーバにあり、 クライアントまたは KDC の問題ではないと考えられます。

Kerberos 化されたアプリケーションを試験する際には、 tcpdump(1) といったパケットスニファを使用して、 パスワードが平文で送られていないことを確認してください。

コア以外の さまざまな Kerberos クライアントアプリケーションが利用可能です。 FreeBSD の 「最小」 インストールでは、 インストールされる Kerberos 化された唯一のサービスは、telnetd(8) です。

Heimdal port は、 Kerberos 化されている ftpd(8), rshd(8), rcp(1), rlogind(8) および他のあまり一般的ではないプログラムをインストールします。 MIT port も、すべての Kerberos クライアントアプリケーションをインストールします。

### 14.5.5. ユーザ設定ファイル: `.k5login` および `.k5users`

レルムのユーザは、一般的には、 ローカルユーザアカウントに対応する Kerberos プリンシパルを持ちます。 しかしながら、時々 Kerberos プリンシパルに対応しないローカルユーザアカウントへのアクセスが必要となることがあります。 たとえば、 `tillman@EXAMPLE.ORG` が、ローカルユーザアカウント `webdevelopers` へのアクセスが必要となることがあります。そして、 他のプリンシパルが同じローカルアカウントにアクセスが必要になることもあります。

ユーザのホームディレクトリに置かれた `.k5login` および `.k5users` ファイルを使うことで、 この問題を解決出来ます。 たとえば、以下の行を含む `.k5login` を `webdevelopers` のホームディレクトリに置くと、 一覧にある両方のプリンシパルは、 共有のパスワードを必要としなくても、 このアカウントにアクセス出来ます。

    tillman@example.org
    jdoe@example.org

`.k5users` の詳細については、 ksu(1) を参照してください。

### 14.5.6. Kerberos Tips, Tricks, およびトラブルシューティング

- Heimdal または MIT Kerberos ports のどちらを使う場合でも、 `PATH` は、 Kerberos 版のクライアント アプリケーションが、 システムにあるアプリケーションより先に見つかるように設定されていることを確認してください。

- レルムにあるすべてのコンピュータの間で時刻が同期していないと、 認証に失敗してしまいます。 NTP を用いた、時刻の同期方法については、 「NTP」 をご覧ください。

- MIT および Heimdal 間の運用は、 標準化されていない kadmin(8) を除けばうまく機能します。

- ホスト名が変更された場合は、 `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(1) に対して、 `root` 権限に setuid を許可しないものがあります。 この設定では、 ksu(1) は動作しないことを意味します。 これは KDC のエラーではありません。

- MIT Kerberos において、 プリンシパルが、デフォルトの 10 時間を超えるチケットの有効期限としたい場合には、 kadmin(8) のプロンプトで `modify_principal` を使って、 対象のプリンシパルおよび `krbtgt` プリンシパル両方の有効期限の最大値を変更してください。 プリンシパルは、 `kinit -l` を使用して、 長い有効期限のチケットを要求できます。

- ### 注記:

  トラブルシューティングのために、 KDC でパケットスニファを走らせ、 一方で、ワークステーションにおいて kinit(1) を実行すると、 kinit(1) を実行するやいなや、 パスワードを入力し終わる前でも、 Ticket Granting Ticket (TGT) が送られてきます。 これに関する説明は、以下の通りです。 Kerberos サーバは、 いかなる未承認のリクエストに対して、 自由に TGT を送信します。 しかしながら、すべての TGT は、 ユーザのパスワードから生成された鍵により、暗号化されています。 そのため、ユーザがパスワードを入力した時には、 パスワードは KDC には送られません。 その代わりこのパスワードは、kinit(1) がすでに入手した TGT の復号化に使われます。 もし、復号化の結果、 有効なチケットで有効なタイムスタンプの場合には、 ユーザは、有効な Kerberos クレデンシャルを持ちます。 このクレデンシャルには、 Kerberos サーバ自身の鍵により暗号化された実際の TGT とともに、将来 Kerberos サーバと安全な通信を確立するためのセッション鍵が含まれています。 この暗号の 2 番目のレイヤは、 Kerberos サーバが、 各 TGT の真偽の検証を可能にしている部分です。

- たとえば一週間といった長い有効期限のチケットを使いたい場合で、 OpenSSH を使って、 チケットが保存されているコンピュータに接続しようとする場合は、 Kerberos `TicketCleanup` が `sshd_config` において `no` と設定されているか、 チケットが、ログアウト時に削除されることを確認してください。

- ホストプリンシパルは長い有効期限のチケットを持つことができます。 もし、ユーザプリンシパルが 1 週間の有効期限を持ち、 接続しているホストが、9 時間の有効期限を持っている場合には、 ユーザキャッシュは有効期限が切れたホストプリンシパルを持つことになり、 想定したように、 チケットキャッシュが振る舞わないことが起こりえます。

- kadmind(8) で説明されているような、 特定の問題のあるパスワードが使われることを避けるために `krb5.dict` を設定する時には、 パスワードポリシが割り当てられたプリンシパルにのみ適用されることを覚えていてください。 `krb5.dict` で使われている形式では、 一行に一つの文字列が置かれています。 `/usr/share/dict/words` にシンボリックリンクを作成することは、有効です。

### 14.5.7. MIT port との違いについて

MIT と Heimdal 版の大きな違いは、 kadmin(8) に関連しています。 このプログラムは、異なる (ただし等価な) コマンド群を持ち、そして、 異なるプロトコルを使用します。 もし KDC に MIT を使用している場合には、 Heimdal 版の kadmin(8) を使って KDC をリモートから (逆も同様に) 管理できないことを意味しています。

クライアントアプリケーションでは、同じタスクを行う際に、 若干異なるコマンドラインのオプションが使われることもあります。 MIT Kerberos ウェブサイト に書かれているガイドに従うことが推奨されます。 path の問題について注意してください。 MIT port はデフォルトで `/usr/local/` にインストールします。 そのため、もし `PATH` においてシステムのディレクトが最初に書かれている場合には、 MIT 版ではなく、「通常の」 システムアプリケーションが起動してしまいます。

### 注記:

FreeBSD の MIT security/krb5 port において、 telnetd(8) および `klogind` 経由でのログインが奇妙な振る舞いをすることを理解するには、 port からインストールされる `/usr/local/share/doc/krb5/README.FreeBSD` を読んで下さい。 「incorrect permissions on cache file」 の振る舞いを修正するには、 フォワードされたクレデンシャリングの所有権を適切に変更できるように、 `login.krb5` バイナリが認証に使われる必要があります。

`rc.conf` を以下のように変更する必要もあります。

    kerberos5_server="/usr/local/sbin/krb5kdc"
    kadmind5_server="/usr/local/sbin/kadmind"
    kerberos5_server_flags=""
    kerberos5_server_enable="YES"
    kadmind5_server_enable="YES"

これを行うのは、 MIT Kerberos のアプリケーションは、 `/usr/local` 構造の下にインストールされるためです。

### 14.5.8. Kerberos で見つかった制限を緩和する

#### 14.5.8.1. Kerberos は、All or Nothing アプローチです。

ネットワーク上で有効なすべてのサービスは、 Kerberos 化されるか、 または、ネットワーク攻撃に対して安全であるべきです。 さもないと、ユーザのクレデンシャルが盗まれ、 利用されることが起きるかもしれません。 この例は、 Kerberos 化されたすべてのリモートシェルです。 パスワードを平文で送るような POP3 メールサーバは変換していません。

#### 14.5.8.2. Kerberos は、 シングルユーザのワークステーションでの使用を想定しています。

マルチユーザの環境では、 Kerberos は安全ではありません。 チケットは `/tmp` に保管され、 このチケットは、すべてのユーザが読むことができるためです。 もし、ユーザがコンピュータを他のユーザと同時に共有していると、 他のユーザは、そのユーザのチケットを盗んだり、 コピーが出来てしまいます。

この問題は、`-c` コマンドラインオプションまたは、好ましくは `KRB5CCNAME` 環境変数によって克服されます。 この問題への対応には、 チケットをユーザのホームディレクトリに保存し、 ファイルの許可属性を設定することが一般的に行われます。

#### 14.5.8.3. KDC は、単一障害点である

設計上、KDC は、 マスターパスワードのデータベースと同様に安全である必要があります。 KDC では、 絶対に他のサービスを走らせるべきではありませんし、 物理的に安全であるべきです。 Kerberos は、 KDC 上で、ファイルとして保存されている同じ 「マスター」 鍵で暗号化されたすべてのパスワードを保存しているので、 非常に危険です。

マスター鍵が漏洩しても、 懸念するほど悪いことにはなりません。 マスター鍵は、Kerberos データベースの暗号時にのみ、 乱数を生成するためのシードとして使われます。 KDC へのアクセスが安全である限りにおいては、 マスター鍵を用いて、それほど多くのことはできません。

さらに、KDC が利用できないと、 認証ができないため、ネットワークサービスを利用できなくなります。 この攻撃による被害は、 ひとつのマスタ KDC とひとつまたはそれ以上のスレーブ、 そして、セカンダリもしくは PAM を用いたフォールバック認証を注意深く実装することにより軽減できます。

#### 14.5.8.4. Kerberos の欠点

Kerberos は、 ユーザ、ホストおよびサービスの間での認証を可能にしますが、 KDC とユーザ、 ホストまたはサービスとの間の認証のメカニズムは提供しません。 これは、トロイの木馬の kinit(1) が、 すべてのユーザ名とパスワードを記録できることを意味しています。 security/tripwire のような、ファイルシステムの完全性を確認するためのツールにより、 この危険性を軽減することができます。

### 14.5.9. Kerberos および ssh(1) を用いたアクセスの問題

Kerberos と ssh(1) を使う場合には、 両者に関して知っておかねばならない問題がいくつかあります。 Kerberos は大変優れた認証プロトコルですが、Kerberos 化された telnet(1) および rlogin(1) には、 バイナリストリームを扱うのに不向きになるようなバグがあります。 デフォルトでは、Kerberos は `-x` を使わない限りセッションを暗号化してくれません。 一方 ssh(1) では、 デフォルトですべてを暗号化してくれます。

ssh(1) はとても良く動作しますが、 デフォルトで暗号鍵を転送してしまいます。 このため、ssh(1) を安全なワークステーションから、 安全でないマシンへのアクセスに使っているユーザに、 セキュリティリスクを引き起こします。 鍵そのものが見えてしまうわけではありませんが、 ssh(1) は login している間、転送用ポートを作ります。 攻撃者が安全でないマシンの `root` を破ったら、 このポートを使って、 この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。

可能な時はいつでも、スタッフのログインには Kerberos を組み合せた ssh(1) を使用することを勧めます。 ssh(1) は、Kerberos 対応機能と一緒にコンパイルできます。 このようにすることで、見えてしまう可能性のある SSH 鍵への依存を減らし、 一方で、Kerberos 経由によりパスワードが保護されます。 鍵は、安全なマシンからの自動化されたタスクのみに使用すべきです。 Kerberos はこの用途には不向きです。 また、SSH の設定で鍵転送をしないようにするか、 あるいは `authorized_keys` の `from=IP/DOMAIN` を使用して、 特定のマシンからログインしてきたときのみ鍵が有効にすることをお勧めします。

### 14.5.10. リソースおよび他の情報源

- The Kerberos FAQ

- Designing an Authentication System: a Dialog in Four Scenes

- RFC 1510, The Kerberos Network Authentication Service (V5)

- MIT Kerberos home page

- Heimdal Kerberos home page

戻る〓 | 上に戻る | 〓次へ
14.4. TCP Wrappers〓 | ホーム | 〓14.6. OpenSSL

本文書、および他の文書は https://download.freebsd.org/ftp/doc/ からダウンロードできます。

FreeBSD に関する質問がある場合には、 ドキュメント を読んだ上で <questions@FreeBSD.org> まで (英語で) 連絡してください。
本文書に関する質問については、 <doc@FreeBSD.org> まで電子メールを (英語で) 送ってください。