前のページ 次のページ 目次

5. セキュリティと NFS

断っておきますが、私はコンピュータセキュリティの専門家ではまったく ありません。しかしこれまでいくつかの障害を乗り越えて来たこともあります ので、セキュリティに関して多少は役に立つアドバイスをすることがで きると思います。しかし注意して下さい。ここに書いてあることは NFS の問 題をすべてリストアップしたものではないのです。もしここに書いてあること を実行しただけで「もう安心だ」と思った方は、とんだお人好しというもので す。「幸運を呼ぶツボ」とかを売りつけられないように気を付けた方が良いで すよ :-)。

以下のような状況なら、この章の内容は必要ありません:あなたのホスト が所属しているのが閉じたネットワークで、そこにいる全てのユーザは 信用がおけ、そうでない人はネットワーク上のマシンにアクセスできないよう になっている場合です。つまりネットワークに対するダイアルアップ接続は禁 止、他のネットワークにへの接続も禁止(そのネットのユーザが全員信頼でき て、同様のセキュリティを確保している場合は別)です。偏執に過ぎると思 いますか?全然そんなことはないんですよ。これはセキュリティに関するごく 基本的な考え方に過ぎません。それに、覚えておいて下さい、私がこれから述 べることはごく基本的なことなのです。安全なサイトを構築するには、 熱心で知識が深く、潜在的なセキュリティ上の問題点に関する最新情報の情報 源を知っているような管理者が不可欠です。

NFS の基本的な問題点は、特に指定をしなければクライアントとサーバが お互いを信頼しあってしまうところにあります。これはまずいわけで、例えば サーバの root アカウントが破られたら、クライアントの root アカウントを 破るのも非常に簡単になってしまうわけです(逆もまたしかり)。この問題を 避ける方法はいくつかあり、後で説明する予定です。

CERT のセキュリティに関する勧告を読んでおくようにしましょう。この文 書の以下のほとんども、CERT が勧告した内容を扱っています。最新の勧告の リストは ftp://ftp.cert.org/01-README で見ることができます。 NFS 関連の勧告を以下にいくつか挙げておきます。


CA-91:21.SunOS.NFS.Jumbo.and.fsirand                            12/06/91
     Vulnerabilities concerning Sun Microsystems, Inc. (Sun) Network
     File System (NFS) and the fsirand program.  These vulnerabilities
     affect SunOS versions 4.1.1, 4.1, and 4.0.3 on all architectures.
     Patches are available for SunOS 4.1.1.  An initial patch for SunOS
     4.1 NFS is also available. Sun will be providing complete patches
     for SunOS 4.1 and SunOS 4.0.3 at a later date.

CA-94:15.NFS.Vulnerabilities                                    12/19/94
     This advisory describes security measures to guard against several
     vulnerabilities in the Network File System (NFS). The advisory was
     prompted by an increase in root compromises by intruders using tools
     to exploit the vulnerabilities.

CA-96.08.pcnfsd                                                 04/18/96
     This advisory describes a vulnerability in the pcnfsd program (also
     known as rpc.pcnfsd). A patch is included.

5.1 クライアント側のセキュリティ

クライアント側では、サーバを信頼しすぎないように設定することが可能 で、これはマウント時のオプションで指定します。例えば NFS ファイルシス テムにある suid されたプログラムを動作させないようにするには nosuid オプションを使います。これは良い設定で、NFS マウントする全 てのディスクに導入を考えるべきだと思います。これを用いないと、サーバの root ユーザがクライアントでも root 権限を奪うことができてしまいます。 suid プログラムをサーバのファイルシステムに作り、クライアントに一般ユー ザでログインして先ほどの suid プログラムを実行すれば... おわかりですね? マウントしたファイルシステム上のファイルの実行をすべて禁止することもで きます。これには noexec オプションを用います。ただ、これは実際に は nosuid に比べてだいぶ不便になってしまうでしょう。どんなファイ ルシステムにも実行しなければならないスクリプトやプログラムの類がいくつ かは入っているでしょうから。これらのオプションは /etc/fstab のオプションの列に、 rsizewsize などと一緒にコンマで区切っ て記述します。

5.2 サーバ側のセキュリティ: nfsd

サーバ側では、クライアントの root アカウントを信頼しないように設定 することができます。これには exports に記述する際、 root_squash オプションを用います。


/mn/eris/local apollon(rw,root_squash)

こうすると、クライアントで UID 0 のユーザがファイルにアクセス(read, write, delete)しようとすると、サーバは UID をサーバにおける "nobody" アカウントのものと置き換えます。つまりサーバの root だけにアクセスや変更が許されているファイルに対して、クライアント の root がアクセスや変更を行うことができなくなるのです。これも良い設定 で、 export する全てのファイルシステムに root_squash を用いるべき だと思います。「でもクライアントの root ユーザは `su' を使って他のユー ザになって、そのユーザのファイルを変更できちゃうじゃないですか!」と言 う意見があるかもしれません。その通り。それが Unix と言うものです。この 意見には重要な側面があります。重要なバイナリやファイルなどは root によって保有されるべきで、 bin などの root 以外のアカウントにする べきではありません。なぜならクライアントの root ユーザがアクセスできな いのはサーバの root アカウントのファイルだけだからです。 nfsd の man ページには他にも何種類かの排他オプションが記述されています。これらを用 いれば、好きな(あるいは嫌いな)クライアントユーザを信頼しないように設 定できます。また UID や GID の範囲によって排他機能を設定することもオプ ションで指定できます。これは Linux の nfsd の man ページに記述されています。

もう一つ重要なことは、 nfsd に対する特権ポートからの接続要求がチェッ クされているかどうかを確認しておくことです。もしクライアントからの要求 をどんなポートからでも受け入れてしまうと、 NFS プロトコルを話す適当な プログラムを用いて、特権を持たないクライアントユーザが他のユーザに成り すますことができてしまいます(このようなプログラムはインターネットで容 易に入手できます)。 Linux の nfsd はデフォルトでこのチェックをするよう になっていますが、他の OS では手動でこのチェックを指定しなければならな いかもしれません。この作業はその OS の nfsd の man ページに記述されて いるはずです。

最後にもう一つ。ファイルシステムを `localhost' や 127.0.0.1 に対し て export してはなりません。この点に関しては私を信用して下さい。

5.3 サーバ側のセキュリティ: ポートマッパ

初期のポートマッパと nfsd の組み合わせには設計上の問題があり、 NFS サーバのファイルへのアクセスが特権無しに可能になってしまいます。幸 運なことに Linux のポートマッパはこの攻撃に対して比較的安全になってい ます。また二つのファイルを用いたアクセスリストを設定することによって、 さらに安全にできます。

まず /etc/hosts.deny を編集します。以下の行を書き込みます。


portmap: ALL

こうするとどこからのアクセスも受け付けなくなります。これはちょっと極端 にすぎるので、/etc/hosts.allow を編集してポートを再び開けるこ とになります。まずどのクライアントに開けるかを決める必要があります。ま ずサーバのポートマッパにアクセスする必要のあるマシンをリストアップしま す。しっかりと設定されたシステムでは、ポートマッパのあらゆるポートにア クセスが必要なマシンというのは非常に少ないはずです。ポートマッパは nfsd と mountd、 ypbind/ypserv、 pcnfsd、 そして ruptime や rusers な どの 'r' コマンド群を管理します。このうち nfsd と mountd、 ypbind/ypserv そして pcnfsd のみが問題の対象となるものです。 ホストマシンのサービスにアクセ スが必要なマシンには許可を与えなければなりません。例えばサーバのアドレ スが 129.240.223.254 で、サブネット 129.240.223.0 にあるクライアントホ ストにアクセス許可を与えるとします(これは networking HOWTO と同じ例で す。必要があったら networking HOWTO をもう一度見に行って、あなたの脳の メモリをリフレッシュして下さい)。この場合は hosts.allow に以下の ように書きます。


portmap: 129.240.223.0/255.255.255.0

これは route コマンドで用いたネットワークアドレス及び ifconfig で用いたサブネットマスクと同じです。この場合 eth0 デバイスに対する ifconfig の結果は以下のようになっているはずです。


…
eth0      Link encap:10Mbps Ethernet  HWaddr 00:60:8C:96:D5:56
          inet addr:129.240.223.254  Bcast:129.240.223.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:360315 errors:0 dropped:0 overruns:0
          TX packets:179274 errors:0 dropped:0 overruns:0
          Interrupt:10 Base address:0x320 
…

同様に netstat -rn とすると以下のようになるはずです。


Kernel routing table
Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
…
129.240.223.0   0.0.0.0         255.255.255.0   U     0      0   174412 eth0
…

(最初の列はネットワークアドレスになります)

hosts.denyhosts.allow ファイルに関しては同名の man ペー ジに記述があります。

訳注: 訳者のところでは "man 5 hosts_access" でした。

重要: portmap の行には IP 番号以外のものは書かないで下さ い。ホストネームの問い合わせは間接的にポートマッパを呼び出すことがあり、 するとまたホストネームの問い合わせが生じてポートマッパが呼び出されホス トネームの問い合わせが...

以上であなたのサーバは随分しっかりしたはずです。残る問題は(そう、 まだあるんですよ)、信頼しているマシンで root が破られた場合(あるいは MS-DOS がブートされた場合)くらいです。このとき root 権限を利用すると 信頼したポートを通して他のユーザに成りすますような要求を出すことが可能 になってしまいます。

5.4 NFS とファイアウォール

ルータやファイアウォールを用いて NFS やポートマッパのポートを塞ぐのは 非常に良い考えです。 nfsd は通常ポート 2049 の tcp/udp を用います。ポー トマッパはポート 111 の tcp/udp、 mountd は 745 と 747 の tcp/udp を使 います。これらのポートは rpcinfo -p で調べる事ができます。

逆に NFS にファイアウォールを越えさせたい場合は、最近の nfsd や mountd にあるオプションを使って特定の(非標準な)ポートを用いるようにし、その ポートをファイアウォールで開ければ良いでしょう。

5.5 まとめ

hosts.allow/denyroot_squashnosuid と特権ポー ト関連の機能を用い れば、現在知られているポートマッパと NFS に関連した多くの問題を避ける ことができ、少なくとも多少は安心することができます。しかし /home/var/spool/mail が NFS マウントされていると、 あなたのネットワークへの侵入者は .forward やメールボックスのファ イルに特殊なコマンドを埋め込んでしまうことができます。同じ理由から、 PGP の秘密鍵を NFS アクセスできるようにするべきではありません。あるい は少なくとも危険性を知っていなければなりません(今や知ったわけですが)。

NFS とポートマッパは複雑なシステムの組み合わせからなっているので、 将来にわたって基本設計や実装にバグが発見されないとは限りません。あるい は現時点においても穴が存在していて、誰かが悪用しているかもしれないので す。まあそれが人生と言うものです。このように物事に遅れないためには、少 なくとも comp.os.linux.announcecomp.security.announce などには目を通しておく必要があるでしょう。


前のページ 次のページ 目次