Show Table of Contents
9.8. NFS の保護
ファイルシステム全体を既知の大量のホスト群で透過的に共有する場合に NFS は非常に適しています。ただし、使いやすさがある反面、安全上の各種の問題も付随します。サーバー上に NFS ファイルシステムをエクスポートする際や、クライアントにマウントする場合には次のセクションを考慮に入れるようにしてください。これにより、リスクを最小限に抑えサーバー上のデータをより効果的に保護することができます。
9.8.1. AUTH_SYS とエクスポート制御による NFS の保護
従来より、NFS ではエクスポートしたファイルへのアクセスを制御するために 2 種類のオプションを提供しています。
1 つ目は、IP アドレスまたはホスト名のいずれかによって、どのホストにいずれのファイルシステムのマウントを許可するかをサーバー側で制限するオプションです。
2 つ目は、ローカルユーザーと同じ方法で、サーバーが NFS クライアント上のユーザーに対してファイルシステムの権限を強制するオプションです。従来より、
AUTH_SYS (AUTH_UNIX とも言う) を使って行われ、ユーザーの UID や GID の指定はクライアントに依存します。つまり、悪意のあるクライアントや誤って定されたクライアントがこれを誤用し、ファイルへのアクセスを許可すべきではないユーザーに対してファイルへのアクセスを簡単に与えてしまうことができるため注意が必要です。
こうしたリスクを抑えるため、管理者によって共通のユーザーおよびグループ ID へのユーザー権限が取り消されたり、読み取り専用のアクセスに制限されたりすることがよくあります。残念ながら、こうしたソリューションは NFS 共有が当初意図されていた方法で使用されることを制限することになります。
また、NFS ファイルシステムをエクスポートしているシステムで使用している DNSサーバーのコントロールが攻撃者に奪われると、特定のホスト名または完全修飾ドメイン名に関連付けられているシステムが未承認のマシンにポイントされる可能性があります。この時点で、NFS マウントにはこれ以上の安全確保を目的としたユーザー名やパスワード情報の交換が行われないため、この未承認のマシンが NFS 共有のマウントを 許可されたシステムになってしまいます。
NFS 経由でディレクトリーのエクスポートを行う際にワイルドカードを使用する場合は慎重に行ってください。ワイルドカードの対象が予定よりも広い範囲のシステムを対象とする可能性があります。
また、TCP ラッパーで
rpcbind[3] サービスへのアクセスを制限することも可能です。iptables でルールを作成しても rpcbind、rpc.mountd、rpc.nfsd などによって使用されるポートへのアクセスを制限することができます。
NFS および
rpcbind に対する安全対策については man iptables を参照してください。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.