8.8. NFS のセキュア化

NFS は、システム全体を、既知の大量のホスト群で透過的に共有する場合に適しています。ただし、使いやすさがある反面、さまざまなセキュリティー問題を伴います。サーバーにおける NFS セキュリティーリスクを最低限に抑え、データを保護するために、サーバー上の NFS ファイルシステムをエクスポートする場合や、クライアントにマウントする場合に、以下のセクションを考慮に入れるようにしてください。

8.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[1] サービスへのアクセスを制限することも可能です。iptables でルールを作成しても rpcbindrpc.mountdrpc.nfsd などによって使用されるポートへのアクセスを制限することができます。
NFS および rpcbind に対する安全対策については man iptables を参照してください。

8.8.2. AUTH_GSS による NFS の保護

NFSv4 には、RPCSEC_GSS および Kerberos バージョン 5 の GSS-API メカニズムの実装が義務付けられ、NFS セキュリティーに大きな変革がもたらされました。ただし、RPCSEC_GSS や Kerberos のメカニズムは、NFS のいずれのバージョンでも利用できます。FIPS モードでは、FIPS が許可するアルゴリズムのみを使用できます。
AUTH_SYS とは異なり、RPCSEC_GSS Kerberos メカニズムでは、ファイルにアクセスしているユーザーを正確に表示することを、サーバーがクライアントに依存しなくなりました。代わりに、暗号を使用してサーバーに対してユーザー認証を行うため、Kerberos 情報を持たない悪意あるクライアントがなりすまし攻撃を行うことはできなくなります。RPCSEC_GSS Kerberos メカニズムでは、Kerberos の設定後、追加の変更を行わなくても動作するため、これがマウントをセキュアにする最も簡単な方法となります。

Kerberos の設定

NFSv4 Kerberos に対応するサーバーを設定する前に、KDC (Kerberos Key Distribution Centre) をインストールして設定する必要があります。Kerberos は、対象暗号化と信頼されているサードパーティー (KDC) を使用したネットワーク認証システムで、これによりクライアントとサーバーが互いに認証できるようになります。Red Hat は、Kerberos の設定に IdM (Identity Management) を使用することが推奨されます。

手順8.3 IdM が RPCSEC_GSS を使用するように、NFS サーバーおよびクライアントを設定する

    • NFS サーバーサイドに、nfs/hostname.domain@REALM プリンシパルを作成します。
    • サーバーサイドとクライアントサイドに、host/hostname.domain@REALM プリンシパルを作成します。
    • クライアントとサーバーの各キータブに該当するキーを追加します。
    詳細は、Red Hat Enterprise Linux 7 Linux ドメイン ID、認証、およびポリシーガイドサービスエントリーおよび Keytab の追加と編集」セクションと「Kerberos 対応の NFS サーバーの設定」セクションを参照してください。
  1. サーバーサイドでは、sec= オプションを使用して、必要なセキュリティーフレーバーを有効にします。すべてのセキュリティーフレーバーと非暗号化マウントを有効にするには、次のコマンドを実行します。
    /export *(sec=sys:krb5:krb5i:krb5p)
    sec= オプションを使用するのに有効なセキュリティーフレーバーは、以下のようになります。
    • sys: 非暗号化保護、デフォルト
    • krb5: 認証のみ
    • krb5i: 整合性保護
    • krb5p: プライバシー保護
  2. クライアントサイドでは、sec=krb5 (設定によっては sec=krb5i もしくは sec=krb5p となります) をマウントオプションに追加します。
    # mount -o sec=krb5 server:/export /mnt
    NFS クライアントの設定方法は、Red Hat Enterprise Linux 7 Linux ドメイン ID、認証、およびポリシーガイドの「Kerberos 対応の NFS クライアントの設定」セクションを参照してください。

関連資料

8.8.2.1. NFSv4 による NFS の保護

NFSv4 には、Microsoft Windows NT モデルの機能や幅広い導入の経緯があるため、POSIX モデルではなく、Microsoft Windows NT モデルをベースとした ACL サポートが含まれます。
NFSv4 でセキュリティーに関する、もう 1 つの重要な特長は、ファイルシステムをマウントする際に MOUNT プロトコルを使用する必要がなくなりました。この MOUNT プロトコルには、ファイル処理の方法にセキュリティー上欠点がある可能性のあることが指摘されています。

8.8.3. ファイル権限

リモートホストにより、NFS ファイルシステムが読み取り、または読み取り/書き込みの権限でマウントされると、それぞれの共有ファイルを保護できるのはその権限のみになります。同じユーザー ID 値を共有している 2 ユーザーが同じ NFS ファイルシステムをマウントすると、それらのユーザーはファイルを相互に変更することができます。さらに、クライアントシステムに root としてログインするいずれのユーザーも、su - コマンドを使用して NFS 共有経由のファイルにすべてアクセスできます。
デフォルトでは、アクセス制御リスト (ACL) は Red Hat Enterprise Linux 環境下の NFS によってサポートされます。Red Hat は、この機能を有効な状態にしておくことを推奨しています。
NFS はファイルシステムをエクスポートする際に、デフォルトで root squash の機能を使用します。これにより、そのローカルマシン上で root ユーザーとして NFS 共有にアクセスするすべてのユーザーの ID は nobody に設定されます。Root squash 機能はデフォルトオプションの root_squash で制御されます。このオプションの詳細については、/etc/exports 設定ファイル」 を参照してください。できる限りこの root squash 機能は無効にしないでください。
NFS 共有を読み取り専用でエクスポートする場合、all_squash オプションの使用を考慮してください。このオプションにより、エクスポートしたファイルシステムにアクセスするすべてのユーザーは nfsnobody ユーザーのユーザー ID を取得します。