VPNアドレスに固定されたNFSエクスポート：それが証明しないこと
エクスポートルールが確認するのはパケットの出所だけです。AUTH_SYSはローカルUIDを主張し、Kerberosはユーザーを認証します。ファイルサービスに必要なのはどちらかを決めてください。
ホストがディレクトリをVPNアドレスにエクスポートし、マウントが成功すると、その設計は認証済みとして記録されます。そのルールが実際に制約しているのは、パケットがどこから来たように見えるかだけです。ファイル操作を進めている人物が本人かどうかはNFSのセキュリティフレーバーに依存し、この種のエクスポートのほとんどでは誰も既定値から変更していません。
ひとつのリクエストに三つのアイデンティティが現れうる
VPNピアはクライアント証明書やピア鍵といった登録済みのアイデンティティを保持します。内側のIPパケットは送信元アドレスを保持します。ファイル操作は、そのNFS機構が提供するユーザー資格情報を保持します。アドレスを三つの代理とみなす設計は、検証すべき部分を静かに仮定してしまっています。
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
その三行を書き出すことが演習のすべてです。エクスポートが安全かどうかの議論の大半は、どの統制がどの行に属するかが明らかになれば崩れます。
アドレスの所有は実装の詳細
ゲートウェイは受け入れたピアにトンネルアドレスを割り当てることも、ルーティングされたサブネットを許可することもできます。そのうえで実装が、内側の送信元が別のクライアントに属するパケットを拒否するかどうかはその実装の性質であり、仮定せずに確認する価値があります。
従来のCommunity版OpenVPNのユーザー空間サーバーコードは、たとえば、パケットがTUNデバイスを通じて配信される前に、別のクライアントに紐づく送信元を拒否できます。これは実質的な価値のあるアドレス所有の確認ですが、どのアカウントが操作を行っているかについては何も語らないため、それでもNFSのユーザー認証ではありません。
送信元の変換はそれさえも侵食します。NATゲートウェイはすべてのクライアントを一つのアドレスとして見せることができ、その時点でエクスポートルールはその背後の人々を区別できません。ルールの見かけの精度は、図によって保たれる虚構になります。エクスポートが重要なら、誰が誰として数えられるかを翻訳者に決めさせず、アドレス指定を明示的に保ってください。
エクスポートを信頼する前にセキュリティフレーバーを読む
Red HatのNFSガイドは、AUTH_SYSを通じてローカルのUNIX UIDとGIDを使うsec=sysと、Kerberosの各モードを区別しています。krb5はユーザー認証を追加し、krb5iは完全性保護を追加し、krb5pはトラフィックのプライバシー保護を追加します。
AUTH_SYSの資格情報には呼び出し元のUIDやグループIDといったフィールドが含まれ、RFC 5531はこのフレーバー自体がセキュリティを提供せず外部の保護に依存すると明確に警告しています。VPNの内側で実行してもトランスポートの保護が得られるだけで、パケット内部の主張は何も変わりません。
exportfs -v
showmount -e nfs.example.internalクライアント一覧を読む前に、その出力のフレーバーを読んでください。制限されているように見えるエクスポートが、アドレスだけで制限されている一方、呼び出し元は好きなUIDを主張し続けているかもしれません。
モデルを選び、そのうえで権限を保つ
実際に管理しているクライアントに適したファイルサービスの認証モデルを選んでください。Kerberosは背後にアイデンティティとサービスの配備を必要とするため、マウントオプションを一つ変えるだけでは移行にならず、Kerberosドメイン、プリンシパル、keytabが存在するまで単に失敗します。
どちらのモデルでも、認証されたプリンシパルが何をできるかを制約するエクスポート権限とファイルシステムの認可を保ってください。認証は誰が尋ねているかを示し、認可は答えが「はい」であるべきかを決めます。この二つを一つの設定にまとめてしまうと、移行は以前の構成より多くの権限を与えることになります。
アドレスルールを本来の目的に使う
サービスを承認済みの経路と送信元に限定することは依然として有用で、VPN端点とNFSサーバーが同じマシンを共有する場合のホスト入力ポリシーも含まれます。同じホスト上でローカルに動作するサービスは、トラフィックを転送するルールでは統制できません。この隙間が、私的なはずだったエクスポートの驚くほど多くの例を説明します。トンネルのルールがそれを覆っていると仮定せず、ローカルの入力ポリシーを明示的に確認してください。
別のインターフェースや送信元変換を行うゲートウェイが、予期せずルールを満たすことがないか確認し、それを、アドレスの偽造が機能するマウントを保証するという主張ではなく、来歴を確立する理由として扱ってください。
受け入れケースは一つではなく三つ実行してください。承認済みクライアントが承認済みユーザーとして動く場合から始め、次に一度も承認されていないピアから繰り返し、その次に承認済みユーザーがまだ許されていないことを試します。その後、認可されたクライアントが侵害されたら何が変わるかを問うてください。トランスポート認証はそのマシン上のすべてのプロセスを信頼できるものにはしないため、盗まれた証明書と好奇心旺盛なローカルアカウントは異なる統制を要する別々の問題です。