多くのディストリビューションでは、ユーザ認証について充分安全な設定がなされ ないまま出荷されています。この章では、システム上でのユーザ認証を安全にする 方法をいくつか取り上げます。ただ、それらを実行すればシステムはより安全なも のになりますが、それでセキュリティが完璧になったなどとは決して思わないでく ださい。
/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 ファイルを安全に設定 する二種類の方法について述べます。ひとつは、ほとんど偏執的なもので、もうひとつ はもっと一般的なものです。
/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 ファイルを間違って削除してしまうと、誰もログインできなくなってしまいます。
以下の設定は、もう少しおおらかなものです。
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 モジュールを介して)認証を許しますが、ユーザパスワードを変更することは許可 しません。その認証は許すわけですが、そうしたサービスが認証をしようとした際に 必ずシステムログに警告を残します。
特別な理由がない限り、/etc/pam.d/other は全てに先立って実 装することを強くお薦めします。「デフォルトで安全寄りに振る」ことは、どんな場合 でも良いことです。新たなサービスに認証の権限を与える必要ができたとしても、その サービスについて PAM の設定ファイルを新たに作ればいいだけです。
大部分の 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 |
/etc/pam.d にあるファイルを見ると、いく つかの使わないプログラム用の設定ファイルや、あるいは聞いたこともないプログラム 用のファイルなどがあると思います。 こうしたサービスへの認証を許したとしてもおそらく大きなセキュリティホールには ならないでしょうが、やはりそれらは禁止したほうがいいでしょう。そうしたプログ ラムに対して PAM が認証できないようにする最良の方法は、そうしたファイルの ファイル名を変更することです。認証を要求するプログラムと同じファイル名の設定 ファイルが見つからないので、PAM は /etc/pam.d/other という (おそらく)非常に安全な設定ファイルを最終的に使用します。後ほどそうしたプログラ ムが必要になった場合は、ファイル名を元に戻すだけですべてが意図した通りに動くわ けです。
パスワードクラッキングツールは、アタッカーにとってはシステムを弱体化させる 目的で使用されますが、システム管理者にとっては、システムのパスワードの強さを 確認するための積極目的の道具として利用することも可能です。最も広く使用されて いるパスワードクラッキングツールはふたつあり、それぞれ "crack" と "John the Ripper" です。 crack はおそらく読者の好きなディストリビューションにすでに 同梱されているでしょう。John the Ripper は、http://www.false.com/security/john/index.htmlで入手できます。その ツールをパスワードデータベースに対して実行すれば、表示された結果を見て おそらく驚いてしまうでしょう。
加えて、ユーザパスワードを変更するたびにその強度を crack のライブラリを使って 検証する PAM のモジュールもあります。このモジュールをインストールすると、 ユーザは、最低限度の強度を持つパスワードへの変更でない限り既存のパスワードを 変更できなくなります。
この文書の第二章で取り上げたように、シャドウパスワードと MD5 パスワードを 使うとシステムをもっと安全にすることができます。最近のディストリビューション では、インストールの過程で MD5 や シャドウパスワードをインストールするかどう か尋ねるようになっています。拒否すべき特別の理由がない限り、それらを有効に するべきです。シャドウや MD5 を使わないパスワードからそれらへの変換の手続きは 非常に込み入っているので、この文書の範疇を越えます。次の文書は新しくはない ですが、多少は役に立つかもしれません。 Shadow Password HOWTO(日本語訳)