User Authentication HOWTO Peter Hernberg 日本語訳 / 千旦裕司 2000/05/02 この文書では、Linux スシステム上で、ユーザ情報とグループ情報の保存方法、ユーザ 認証の方法 (PAM)、そしてそのユーザ認証を安全に行う方法について説明します。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents 1. はじめに 1.1. この文書を書いた経緯 1.2. 新バージョンについて 1.3. フィードバック 1.4. バージョン小史 1.5. 著作権と商標 1.6. 謝辞 1.7. 想定する読者 2. ユーザ情報がシステムに保存される仕組み 2.1. /etc/passwd について 2.2. シャドウパスワード 2.3. /etc/group と /etc/gshadow 2.4. MD5 暗号化パスワード 2.5. 煩雑さの解消 3. PAM (Pluggable Authentication Modules) 3.1. なぜ PAM なのか 3.2. PAM とは何か 3.3. PAM の設定 3.4. もっと多くの情報を入手する方法 4. ユーザ認証を安全に行う方法 4.1. 強力な /etc/pam.d/other ファイル 4.2. パスワード無しユーザのログインを禁止する 4.3. 不要なサービスを無効にする 4.4. パスワードクラッキングツール 4.5. シャドウパスワードと MD5 パスワード 5. 活用例 5.1. Apache + mod_auth_pam 5.2. 例題の内容 5.3. mod_auth_pam のインストール 5.4. PAM の設定 5.5. Apache の設定 5.6. 設定のテスト 6. リソース 6.1. PAM 6.2. セキュリティ全般 6.3. オフライン文書 7. 結語 7.1. 日本語訳について 1. はじめに 1.1. この文書を書いた経緯 手元の家庭内ネットワークにいくつか(ほとんど不必要な)ネットワークサービスを追加 しようとしたとき、わたしはいつも認証の問題で泥沼にはまりました。そこで、わたし は意を決して、 Linux システム上での認証の仕組みを理解して HOWTO を書こうと考え ました。そして、その計画をわたしのシニアプロジェクトと呼ぶことにしたのです。等 閑視されがちですが非常に重要な、認証というシステム管理上の問題点について、この 文書が読者の理解の一助となればさいわいです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.2. 新バージョンについて わたしのドメインが順調に立ち上がれば、この文書の最新バージョンはそこで入手でき ます。それまでは、http://www.linuxdoc.org だけで我慢です。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.3. フィードバック コメント、訂正、提案、火事、UFO の目撃談は、こちらまでお願いします。 petehern@yahoo.com ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.4. バージョン小史 v0.1 (May 13, 2000) 最初のバージョン (リリースされず) v0.3 (May 14, 2000) 改訂版 (リリースされず) v0.5 (May 15, 2000) 「ユーザ認証を安全に行う方法」と「リソース」を追加 (リリー スされず) v0.7 (May 15, 2000) 二訂: リリース準備整う ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.5. 著作権と商標 (c) 2000 Peter Hernberg このマニュアルは、以下の条項に従う限り、無料で、全体もしくは部分を複製すること ができます。 ・ 全体もしくは部分を複製する場合、上記著作権表示とこの使用許諾条件が、それ らの複製上に完全な型で記載されていること。 ・ 翻訳もしくは二次的著作物を作成した場合、その配布に先だって、この文書の著 者の承認を得ること。 ・ この文書の一部のみ配布する場合、全文の入手が可能であることの告示とその入 手方法が示されること。 ・ この文書の僅かな部分を、批評や説明の材料として他の著作物に転載する際は、 その引用が正当なものである場合に限り、この許可条項の表記を省略できます。ま た、学術目的の利用については、これらの規定の適用例外となる場合があるので、 著者まで連絡をして尋ねてください。こうした制限は著者としてのわれわれを守る ためであり、学習者や教育者に制限を課すことを意図するものではありません。こ の文書のソースコードには(文書の執筆形式である SGML を除いて)、 GNU General Public License が適用されます。ライセンス文書については、GNU アーカイブから 匿名 FTP を使って入手が可能です。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.6. 謝辞 わたしのことを 18 年間我慢してくれている家族に感謝します。素敵な遊び道具をくれ た Debian の連中に感謝します。わたしを「オタク」にするために給料を払ってくれる CGR に感謝します。Sandy Harris の有益な提案に感謝します。最後に、インスタントラ ーメンの製造会社に感謝したいと思います。わたしはそれなしには生きていけないから です。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.7. 想定する読者 この文書で扱う主題からして、読者は既にコマンドラインで快適にコマンドを実行し、 テキスト形式の設定ファイルの編集をしていることを前提とします。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2. ユーザ情報がシステムに保存される仕組み 2.1. /etc/passwd について ほとんど全ての Linux ディストリビューション(それと商用の *nix など)では、ユーザ 情報は /etc/passwd に保存されています。このファイルはテキストファイルであり、ユ ーザのログイン名、暗号化されたパスワード、固有のユーザ ID 番号(uid と呼ばれま す)、グループ ID 番号(gid と呼ばれます)、任意のコメント(通常は、ユーザの実名、 電話番号などが書かれています)、ホームディレクトリ、そして好みのシェルなどの情報 を含んでいます。/etc/passwd の典型的なエントリーは、以下のようなものです。 pete:K3xcO1Qnx8LFN:1000:1000:Peter Hernberg,,,1-800-FOOBAR:/home/pete:/bin/bash ご覧の通り、非常にストレートな表記になっています。個々のエントリーは上記に見ら れるように 6 つのフィールドを持ち、それぞれのフィールドはコロンで区切られます。 もしこれが、わたしを悩ませたユーザ認証の仕組みと同じくらい複雑であってくれたな ら、この HOWTO は必要なかったでしょう。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.2. シャドウパスワード 読者自身の /etc/passwd ファイルを見れば、実際は以下のようになっているのが分かる でしょう。 pete:x:1000:1000:Peter Hernberg,,,1-800-FOOBAR:/home/pete:/bin/bash 上記では、暗号化されたパスワードはどこに行ったのでしょう？それがどこへ行ったか をお話しする前に、若干の説明が必要です。 /etc/passwd ファイルには、全ユーザの情報とその暗号化されたパスワードが含まれて います。しかし、そのファイルはすべてのユーザに閲覧可能となっています。つまり、 システム上の全員の暗号化されたパスワードが入手可能なわけです。この点、確かにパ スワードは暗号化されてはいますが、パスワードのクラッキングツールの入手はわけも ないことです。したがって、このセキュリティ上の脅威の高まりに対抗するために、シ ャドーパスワードが開発されました。 シャドーパスワードを有効にしたシステムでは、/etc/passwd のパスワードが書かれて いた部分は、x で置き換えられ、実際の暗号化されたユーザパスワードは /etc/shadow ファイルに保存されます。/etc/shadow はルートユーザだけしか読めないので、悪意の あるユーザが同僚のパスワードをクラックすることはできません。 /etc/shadow の各エ ントリーは、ユーザのログイン名、暗号化されたパスワード、そしてパスワードの有効 期限に関係するいくつかのフィールドからなっています。典型的なエントリーは、以下 のようなものです。 pete:/3GJllg1o4152:11009:0:99999:7::: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.3. /etc/group と /etc/gshadow グループ情報は /etc/group ファイルに保存されます。これは前記の /etc/passwd と似 たもので、エントリーにはグループ名、パスワード、id 番号(gid)、それにカンマで区 切られたグループメンバーのフィールドが含まれています。 /etc/group のエントリー は以下のようなものです。 pasta:x:103:spagetti,fettucini,linguine,vermicelli パスワードフィールドの "x" を見てお分かりのように、グループパスワードもシャドー 化できます。グループがグループ自体のパスワードを持つことはほとんどないのですが 、シャドー化されたグループパスワードの情報は /etc/gshadow ファイルに保存される ということに注意してください。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.4. MD5 暗号化パスワード 伝統的には、Unix のパスワードは標準的な crypt() 関数で暗号化されていました。( crypt() 関数の詳細については、crypt(3) のマニュアルページをご覧ください。) しか し、コンピュータの高速化が進むにつれ、この関数で暗号化されたパスワードをクラッ クすることが容易になりました。インターネットが登場すると、多数のホストに対して パスワードクラッキングを実行できるようなツールも入手可能になりました。そこで、 新しいディストリビューションの多くにはより協力な MD5 ハッシュアルゴリズムでパス ワードを暗号化するオプション機能が同梱されるようになっています。 ( MD5 ハッシュ アルゴリズムについての詳しい情報は、RFC1321 をご覧ください) MD5 パスワードはパ スワードクラッキングの脅威を完全に取り除くものではありませんが、パスワードのク ラッキングをずっと難しくすることは確かです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.5. 煩雑さの解消 以上でお分かりのように、ユーザ認証のための情報がシステムに保存される方法には何 種類もあります。(MD5 で暗号化しないシャドウパスワード、MD5 で暗号化した /etc/ passwd などなど) そうだとすると、login や su などのプログラムは、ユーザのパスワ ード認証の方法をどうやって知るのでしょうか？さらに、システム上のパスワードの保 存方法を変更したいときはどうすればいいのでしょう？ユーザのパスワードを必要とす るプログラムは、そのパスワードの保存方法が変更されたことをどうやって知るのでし ょう？ PAM がその答えになります。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3. PAM (Pluggable Authentication Modules) PAM (Pluggable Authentication Modules) は現在的なディストリビューションにおける ユーザ認証の核となるものです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.1. なぜ PAM なのか 古き良き時代の Linux であれば、su や passwd や login あるいは xlock といったプ ログラムは、ユーザ認証の必要が生じた時に、/etc/passwd から必要なユーザ情報を読 み込めばいいだけでした。ユーザパスワードの変更が必要なら、/etc/passwd ファイル を編集するだけでした。しかし、この単純ですが稚拙な方法のために、システム管理者 やアプリケーション開発者は数々の問題に直面することになったのです。MD5 とシャド ーパスワードの利用がだんだんと広がるにつれて、ユーザ認証を必要とするプログラム は、何種類もの異なる認証方法を扱う際にその認証方法に適した情報を得る手段を個別 に知っていなければならなくなったからです。また、認証方式を変更したい場合は、そ うしたすべてのプログラムをコンパイルし直さなければなりませんでした。PAM は、ユ ーザ情報が保存される方法とは無関係な透過的ユーザ認証方式をプログラムに提供する ことで、この煩雑な手続きを一掃したのです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.2. PAM とは何か Linux-PAM System Administrator's Guide から引用すると、「Linux-PAM プロジェクト の目的は、ユーザに何らかの権限を付与するソフトウェアの開発を、安全かつ適切な認 証方式自体の開発から分離することです。この目標は、関数のライブラリを提供し、ア プリケーション側でそれを使ってユーザ認証をリクエストする仕組みを作ることで達成 されました。」つまり、PAM があれば、パスワードが /etc/passwd にあるか、香港のサ ーバ上にあるかといったことは問題ではなくなります。プログラムがユーザ認証を必要 としたときは、PAM が適切な認証方式のための関数を含むライブラリを提供してくれま す。このライブラリは動的にロードされるので、認証方式の変更は設定ファイルの編集 だけで実現可能になるのです。 柔軟性は PAM が最強である理由のひとつです。PAM の設定によって、あるプログラムの ユーザ認証権の行使を禁止したり、特定のユーザだけの認証を可能にしたり、あるいは 、プログラムがユーザ認証をしようとすると警告を発したり、さらに全てのユーザをロ グインできなくしてしまったりできるようになります。PAM のモジュール設計は、ユー ザ認証方法の完全な管理を可能にします。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.2.1. PAM をサポートするディストリビューション いずれほとんど全ての有名ディストリビューションが PAM をサポートするでしょう。以 下は不完全ですが、 PAM をサポートしているディストリビューションの一覧です。 ・ Redhat バージョン 5.0 以降 ・ Mandrake 5.2 以降 ・ Debian バージョン 2.1 以降( 2.1 では部分的サポート、2.2 で完全サポート) ・ Caldera バージョン 1.3 以降 ・ Turbolinux バージョン 3.6 以降 ・ SuSE バージョン 6.2 以降 ・ (訳注) Vine すべてのバージョン ・ (訳注) Kondara すべてのバージョン 上記リストは、不完全なはずですし、不正確でもあるでしょう。このリストへの追加や 修正情報を送ってくれるとうれしいです。 petehern@yahoo.com ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.2.2. PAM のインストール PAM をソースからインストールすることは、時間のかかる作業であり、この HOWTO の範 疇を越えるものです。システムに PAM がインストールされていないなら、おそらく、ア ップグレードすべき理由が他にもいろいろある古いバージョンのディストリビューショ ンを使っているからでしょう。また、自分でインストールしなければ気が済まないとい う人なら、わたしの手助けは不要なはずです。いずれにせよ、ここからは、既に PAM が インストールされていることを前提にします。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.3. PAM の設定 一般的な話はこれくらいにして、問題を掘り下げましょう。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.3.1. PAM の設定ファイル PAM の設定ファイルは、/etc/pam.d に保存されています。 (もし /etc/pam.d というデ ィレクトリがないとしても心配いりません。次章で取り上げます。) そのディレクトリ に行って、中を覗いてみましょう。 ~$ cd /etc/pam.d /etc/pam.d/$ ls chfn chsh login other passwd su xlock /etc/pam.d/$ システムに何をインストールしているかによって、このディレクトリにあるファイルは 多少増減するかもしれません。詳細はどうであれ、システム上でユーザの認証に関わる プログラムごとにひとつのファイルが存在することが分かると思います。既に気付いた かもしれませんが、どのファイルも PAM による認証の設定ファイルなのですが、それぞ れ該当するプログラムと同一の名前が付いています。 ( other だけが例外ですが、これ はすこし後で話します。) それではパスワードに関連した PAM の設定ファイルを見てみ ましょう。(次のファイルは分かり易くするために単純化してあります。) /etc/pam.d/$ cat login # PAM 設定ファイル( login プログラム用 ) auth requisite pam_securetty.so auth required pam_nologin.so auth required pam_env.so auth required pam_unix.so nulok account required pam_unix.so session required pam_unix.so session optional pam_lastlog.so password required pam_unix.so nullok obscure min=4 max=8 このファイルを掘り下げる前に、少し説明すべきことがあります。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.3.2. 少し説明すべきこと 少数の方はこう考えているかもしれません。「えっ！ /etc/pam.d ディレクトリなんて ない。ディストリビューションの収録プログラムリストに PAM は含まれているのに、デ ィレクトリが見つからない。PAM がない人生なんて、空っぽで無意味だ！どうすればい いんだろう？」心配無用です。無くなったのではありません。ディストリビューション に PAM が含まれているのに、 /etc/pam.d がないときは、PAM の設定ファイルは /etc/ pam.conf に保存されているのです。いくつものファイルに分散させるかわりに、PAM の 設定ファイルをまとめてひとつのファイルに保存しているのです。この場合、PAM の設 定はすこしだけ異なった構文になりますが、そこでの設定についてはこの章の Section 3.3.4 「 pam.conf ファイルの設定」で説明します。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.3.3. 設定ファイルの構文 PAM の設定ファイルは以下のような構文になっています。 type control module-path module-arguments login プログラム(先ほどの記述を見てください)の設定ファイルを参考にして、PAM 設 定ファイルの構文を見てみましょう。 PAM の設定字句 type type という字句では、その行のモジュールでどういう認証の型が使用されるべきか を PAM に知らせます。認証の際に複数の要求をユーザに課す場合は、同じ型のモジ ュールを重複して使用することもできます。PAM は次の 4 つの型を認識します。 account ユーザがサービスへのアクセスを許可されているかどうか、パスワードが期限 切れになっていないかなどを(パスワードとは無関係に)確認します。 auth ユーザが自称する通りの本物のユーザかどうかを確かめます。通常はパスワー ドで確認しますが、バイオメトリクス(biometrics)などのもっと洗練された方 法で確かめる場合があるかもしれません。 password ユーザに自分の認証方法を変更するメカニズムを提供します。これも通常はパ スワードの変更によってなされます。 session ユーザの認証前または認証後、あるいはその両方で実行したいことを指定しま す。これには、ユーザディレクトリのマウントやアンマウント、ログインやロ グアウト時のログ記録、ユーザが利用できるサービスを制限したり、その制限 を外したりといったことがなどが含まれるでしょう。 上記 login の設定ファイルでは、type の各々の型が最低でもひとつのエントリー を形成しているのが分かると思います。 login プログラムは、その名前の通りユー ザの「ログイン」そのものを許可するプログラムなので、認証の過程ですべての異 なった型にアクセスする必要があることは納得できると思います。 control control 字句が果たす役割は、認証が失敗したときに何をすべきかを PAM に伝える ことです。PAM が理解するのは次の 4 つの control 型です。 requisite このモジュールを経由して認証に失敗した場合に、即座に認証を拒絶します。 required 認証に失敗した場合に、認証を拒否します。しかし、PAM は、認証拒否をユー ザに知らせる前に、このサービスのためにリストアップされた(同一 type の) 全てのモジュールを実行します。 sufficient このモジュールによる認証が成功した場合、その前の required 型のモジュー ルが認証に失敗していたとしても、PAM はそのユーザに認証を与えます。 optional このモジュールが認証の成否に関して意味を持つのは、そのサービスに関して 、これが(認証の成否を決めるべき)唯一のモジュール型である場合だけです。 login プログラムの設定ファイルでは、異なる control 型のほぼ全てを見ることが できます。required 型のモジュールの大部分は pam_unix.so (メインの認証モジュ ール)です。そして、ひとつの requisite 型のモジュールが pam_securefilenamey.so (ユーザが安全なコンソールでログインしているか確かめ るもの)であり、ひとつの optional 型のモジュールが pam_lastlogin.so (前回ロ グインしたときのユーザの情報を取ってくるモジュール)となっています。 (訳注: control については、新しい構文も開発されています。詳細は、The Linux-PAM System Administrators' Guide をご覧ください) module-path module-path の役割は、どのモジュールを使用するか、(オプションとして)それが どこにあるかを PAM に伝えることです。login の設定ファイルに見られるように、 大部分の設定ファイルではモジュール名だけが含まれています。この場合、PAM は 、PAM 用のデフォルトディレクトリ、通常は /usr/lib/security/ を探します。し かし、もし使っているディストリビューションが Linux ファイルシステムの標準規 格に従っているなら、PAM モジュールは /lib/security ディレクトリにあるでしょ う。 module-arguments module-arguments は、モジュールに渡す引数を指定するものです。それぞれのモジ ュールが自分自身の引数を持っています。例えば、login の設定ファイルであれば 、"nullok" ("null ok" を意味します)という引数は、pam_unix.so モジュールに渡 されますが、その意味は、パスワードとして何も入力しなくても(null)認証される ということです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.3.4. pam.conf ファイルの設定 もし PAM の設定が /etc/pam.d/ ディレクトリではなく、/etc/pam.conf ファイルに保 存されているなら、 PAM の設定の書式は若干異なったものになります。サービスごとに 設定ファイルを持つのではなく、全ての設定が /etc/pam.conf ファイルの中で行われ、 サービス名が各行の先頭の識別情報となります。例えば、/etc/pam.d/login ファイルの 次の行は、 auth required pam_unix.so /etc/pam.conf ファイルでは、以下のようになるでしょう。 login auth required pam_unix.so 上記のちょっとした違いを除けば、残りの全ての PAM の構文がそのまま当てはまります 。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.4. もっと多くの情報を入手する方法 PAM の設定や PAM の全モジュールのリファレンスなど、より詳細な情報が必要なときは 、Linux-PAM System Administrator's Guide を参考にしてください。このガイドは、 PAM の設定に関するあらゆることを説明するもので、最新のリファレンスでもあります 。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4. ユーザ認証を安全に行う方法 多くのディストリビューションでは、ユーザ認証について充分安全な設定がなされない まま出荷されています。この章では、システム上でのユーザ認証を安全にする方法をい くつか取り上げます。ただ、それらを実行すればシステムはより安全なものになります が、それでセキュリティが完璧になったなどとは決して思わないでください。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.1. 強力な /etc/pam.d/other ファイル /etc/pam.d にあるファイルは全て、特定のサービスに関する設定をするためのものです 。このルールに対する注目すべき例外が、 /etc/pam.d/other ファイルです。このファ イルは、自分自身の設定ファイルを持たないサービス全部の設定をするものです。例え ば、(実際は存在しませんが) xyz というサービスがユーザ認証をしようとした場合、 PAM は /etc/pam.d/xyz というファイルを探します。それが見つからないと、認証は / etc/pam.d/other ファイルに従ってなされます。/etc/pam.d/other ファイルは PAM サ ービスの最後の拠り所となっているので、その安全性は重要な意味を持ちます。ここで は /etc/pam.d/other ファイルを安全に設定する二種類の方法について述べます。ひと つは、ほとんど偏執的なもので、もうひとつはもっと一般的なものです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.1.1. 偏執狂の設定 /etc/pam.d/other の偏執的な設定は以下のようになります。 auth required pam_deny.so auth required pam_warn.so account required pam_deny.so account required pam_warn.so password required pam_deny.so password required pam_warn.so session required pam_deny.so session required pam_warn.so 上記の設定にしておけば、不明なサービスが設定ファイルの 4 つの型のいずれにアクセ スしようとする場合でも、PAM は(pam_deny.so モジュールを介して)認証を拒絶し、 (pam_warn.so モジュールを介して)システムログに警告を残します。 PAM にはバグがほ とんどないので、この設定は冷酷とも言える安全性を発揮します。この冷酷さの問題点 は、もしたまたま他のサービスの設定を削除してしまった場合に問題が起きるかもしれ ないということです。/etc/pam.d/login ファイルを間違って削除してしまうと、誰もロ グインできなくなってしまいます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.1.2. もう少し親切な設定 以下の設定は、もう少しおおらかなものです。 auth required pam_unix.so auth required pam_warn.so account required pam_unix.so account required pam_warn.so password required pam_deny.so password required pam_warn.so session required pam_unix.so session required pam_warn.so この設定では、不明なサービスに対しても(pam_unix.so モジュールを介して)認証を許 しますが、ユーザパスワードを変更することは許可しません。その認証は許すわけです が、そうしたサービスが認証をしようとした際に必ずシステムログに警告を残します。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.1.3. /etc/pam.d/other の重要性 特別な理由がない限り、/etc/pam.d/other は全てに先立って実装することを強くお薦め します。「デフォルトで安全寄りに振る」ことは、どんな場合でも良いことです。新た なサービスに認証の権限を与える必要ができたとしても、そのサービスについて PAM の 設定ファイルを新たに作ればいいだけです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.2. パスワード無しユーザのログインを禁止する 大部分の Linux システムでは、ftp や webserver, mail ゲートウェイなどある種のシ ステムサービスに権限を与えるために、「ダミー」のユーザアカウントがいくつか存在 します。確かに、アカウントが乗っ取られても、アタッカーはルート権限で実行されて いるサービスではなくダミーアカウントに付与された限定的な権限しか入手できないの ですから、こうしたアカウントがあるとシステムはより安全になると言えなくもありま せん。しかし、こうしたダミーアカウントはパスワードなし(null)でログインできてし まう場合が普通なので、そうしたログインの権限を与えることは、ひとつのセキュリテ ィーリスクとなります。パスワードなしでログインを許す設定オプションは、"nullok" というモジュール引数(module-argument)です。ログインを許可するサービスについては 、その "auth" タイプの全てのモジュールからこの引数を削除するようにすべきでしょ う。そうしたサービスとは、通常 login サービスのことですが、 rlogin や ssh など も含まれるかもしれません。そうすると、/etc/pam.d/login の次の行は、 auth required pam_unix.so nullok 以下のように変更されるべきです。 auth required pam_unix.so ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.3. 不要なサービスを無効にする /etc/pam.d にあるファイルを見ると、いくつかの使わないプログラム用の設定ファイル や、あるいは聞いたこともないプログラム用のファイルなどがあると思います。こうし たサービスへの認証を許したとしてもおそらく大きなセキュリティホールにはならない でしょうが、やはりそれらは禁止したほうがいいでしょう。そうしたプログラムに対し て PAM が認証できないようにする最良の方法は、そうしたファイルのファイル名を変更 することです。認証を要求するプログラムと同じファイル名の設定ファイルが見つから ないので、PAM は /etc/pam.d/other という (おそらく)非常に安全な設定ファイルを最 終的に使用します。後ほどそうしたプログラムが必要になった場合は、ファイル名を元 に戻すだけですべてが意図した通りに動くわけです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.4. パスワードクラッキングツール パスワードクラッキングツールは、アタッカーにとってはシステムを弱体化させる目的 で使用されますが、システム管理者にとっては、システムのパスワードの強さを確認す るための積極目的の道具として利用することも可能です。最も広く使用されているパス ワードクラッキングツールはふたつあり、それぞれ "crack" と "John the Ripper" で す。 crack はおそらく読者の好きなディストリビューションにすでに同梱されているで しょう。John the Ripper は、http://www.false.com/security/john/index.htmlで入手 できます。そのツールをパスワードデータベースに対して実行すれば、表示された結果 を見ておそらく驚いてしまうでしょう。 加えて、ユーザパスワードを変更するたびにその強度を crack のライブラリを使って検 証する PAM のモジュールもあります。このモジュールをインストールすると、ユーザは 、最低限度の強度を持つパスワードへの変更でない限り既存のパスワードを変更できな くなります。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.5. シャドウパスワードと MD5 パスワード この文書の第二章で取り上げたように、シャドウパスワードと MD5 パスワードを使うと システムをもっと安全にすることができます。最近のディストリビューションでは、イ ンストールの過程で MD5 やシャドウパスワードをインストールするかどうか尋ねるよう になっています。拒否すべき特別の理由がない限り、それらを有効にするべきです。シ ャドウや MD5 を使わないパスワードからそれらへの変換の手続きは非常に込み入ってい るので、この文書の範疇を越えます。次の文書は新しくはないですが、多少は役に立つ かもしれません。 Shadow Password HOWTO(日本語訳) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5. 活用例 この章では、簡単な実例を挙げます。前章の内容をまとめるのに役立つかと思います。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5.1. Apache + mod_auth_pam ここでは、例として、mod_auth_pam という Apache のモジュールのインストールと設定 を行います。これは、PAM を使ってウェブサーバのユーザを認証するのに利用されるも のです。この例題の趣旨は PAM にあるので、 Apache については既にインストールされ ているものとします。まだインストールされていないなら、利用している Linux の配布 元で、インストール用パッケージが見つかるはずです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5.2. 例題の内容 この例題の目標は、ウェブサーバ上に、制限のかかった family というディレクトリを 作成し、 PAM を介したユーザ認証をその領域に設定することです。そのディレクトリに は family のメンバーの個人情報を置くので、ユーザグループ family の一員でないと アクセスできないようにします。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5.3. mod_auth_pam のインストール 最初に、mod_auth_pam を http://blank.pages.de/pam/mod_auth_pam からダウンロード してください。そして、次のコマンドで mod_auth_pam をコンパイルします。 ( root でログインすることが必要です) ~# tar xzf mod_auth_pam.tar.gz ~# cd mod_auth_pam-1.0a ~/mod_auth_pam-1.0a# make ~/mod_auth_pam-1.0a# make install もし mod_auth_pam をインストールするときに問題が生じたら、ディストリビューショ ンに付属している apache-dev というパッケージをインストールしているかどうか確認 してください。 mod_auth_pam のインストールが終わったら、Apache を再起動する必要 があります。Apache は通常次のコマンドで再起動できます。(ここでも、root でないと いけません) ~# /etc/init.d/apache restart ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5.4. PAM の設定 Apache のための PAM の設定ファイルは /etc/pam.d/httpd にあります。デフォルトの 設定(これは mod_auth_pam をインストールしたときに同時にインストールされていま す)は、安全ではありますが、 pam_pwdb.so というモジュールを使っていて、このモジ ュールは多くのシステムでは入手できないかもしれません。(それにいちから設定してい くほうが楽しいですから。) したがって、/etc/pam.d/httpd というファイルは削除して 、最初からスタートしましょう。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5.4.1. PAM の設定方法を決める Apache の認証要求を PAM が処理する方法を定める前に、PAM が必要なのは何をチェッ クするためなのかを正確に理解しなければなりません。まず、PAM を使うのは、標準的 な Unix パスワードデータベースにあるパスワードとユーザのパスワードが一致するか どうかを確認させるためです。だとすると、"auth " 型に "pam_unix.so" モジュールと いうのが使えそうです。正しいパスワードが入力されないと認証が失敗するようにする ために、モジュールの control 型は "required" にセットしするのがいいでしょう。以 下は、この場合の /etc/pam.d/httpd ファイルの最初の行がどうなるかを示したもので す。 auth required pam_unix.so 次に、ユーザのアカウントが有効になっているかどうか確認しなければなりません。 (つまり、ユーザのパスワードの有効期限が切れているなどの問題がないかどうかという ことです。) これは "account" タイプの問題で、その機能についても pam_unix.so モ ジュールで提供されています。再度、このモジュールの "control" タイプを " required" に設定します。その行を追加し終わると、/etc/pam.d/httpd の設定は以下の ようになります。 auth required pam_unix.so account required pam_unix.so 上記の設定は非常に洗練されているとは言い難いですが、しっかり機能します。 PAM の サービスの設定方法を学ぶスタートとしては悪くないはずです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5.5. Apache の設定 PAM は Apache からの認証要求を処理できるように設定されたので、今度は Apache が PAM の認証を適切に利用して family ディレクトリへのアクセスを制限できるように設 定しましょう。それをするには、次の数行を httpd.conf ファイルに付け加えてくださ い。 ( httpd.conf ファイルは通常 /etc/apache か /etc/httpd ディレクトリにありま す) AuthPAM_Enabled on AllowOverride None AuthName "Family Secrets" AuthType "basic" require group family もしかすると、上記の /var/www の部分は、ウェブ関係の文書がデフォルトで置かれて いる /home/httpd といった場所に変更しなければならないかもしれません。その場所が どこであろうとも、そこに family というディレクトリを作成する必要があります。 今回の設定をテストする前に、今編集した Apache の設定について簡単に説明したいと 思います。 ディレクティブ(directive)は、このディレクトリに関する設定 データをカプセル化するために使用されます。そして、このディレクティブの内部では 、まず、PAM の認証機能を有効にして ("AuthPAM_enabled on")、この設定の上書きを禁 止し(" AllowOverride none")、この認証領域の名前を "Family Secrets " としていま す("AuthName "Family Secrets"")。そして、httpd の認証タイプ(PAM による認証では ありません)をデフォルトにセットした上で("AuthType "basic"")、ユーザグループとし て family の接続を許可する設定("require group family")にしました。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5.6. 設定のテスト これで全ての設定が問題なく終了したので、成功を祝いましょう。さっそくお気に入り のブラウザを起動させて、http://your-domain/family/ に突進しましょう。 (your-domain の部分には、えーっと、あなたのドメイン名(your-domain)を入れてくだ さい) これであなたは完全な認証を受けた者(uber-authenticator)になったわけです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 6. リソース オンライン、オフラインともに多くのリソースがありますから、ユーザ認証に関するよ り多くの情報をそこで収集できます。もしこのリストに付け加えるべきリソースを御存 知なら、わたしまで書き送ってください。 petehern@yahoo.com ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 6.1. PAM ・ Linux-PAM System Administrator's Guide ・ Linux-PAM Module Writer's Manual ・ Linux-PAM Application Developer's Manual ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 6.2. セキュリティ全般 ・ linuxsecurity.com ・ securitywatch.com ・ Security HOWTO (日本語訳) ・ Packetstorm ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 6.3. オフライン文書 システムのマニュアルページを使えば、かなりの情報が集められます。以下はユーザ認 証に関係するマニュアルページです。丸カッコの中の数字はマニュアルページのセクシ ョン番号です。passwd(5) のマニュアルページを見るには、man 5 passwd と打ち込んで ください。 ・ passwd(5) ・ crypt(3) ・ pam.d(5) ・ group(5) ・ shadow(5) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 7. 結語 この HOWTO が役に立つことを願っています。質問、コメント、提案などがあれば、メー ルをもらえるとたいへん嬉しく思います。メールの宛先はこちらです。 petehern@yahoo.com ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 7.1. 日本語訳について 翻訳千旦裕司 校正武井伸光 ご連絡は、JF@linux.or.jp か、訳者 ysenda@pop01.odn.ne.jp までお願いします。