## page was renamed from NFSv4/Memo_Of_NFS_Security_MEMO
## page was renamed from NFSv4/MemoOfＮＦＳセキュリティメモ
ＮＦＳについてググって見ると使用状況に応じて色々と苦労している点が見られる。
Kerberos 必須という人も居れば不要という人も居るわけで、ここでは以下のアンセキュアな環境を前提とする。

=== 専用ＮＩＣ（ＶＬＡＮ）割り当て ===
ＮＦＳ共有用に専用ＮＩＣ（ＶＬＡＮ）を割り当てる。そのＮＩＣにはＮＦＳ以外のサービスは提供しない。

 * ＧｂＥはいいぞ。単体～数台なら十分以上の性能を発揮する。
 * これは「同時」数台が帯域を使い込むような状態を想定しているので、数台がネットワークに存在するだけで飽和することを意味しない:-)。
 * 可能なら１０ＧｂＥだろうけど高いし。
 * 検証環境では同一ホスト内にＮＦＳサーバーとＮＦＳクライアントを共存させてみたが、単純に / 以下を対象に tar(1) で固めただけで、１．６Ｇｂｐｓ の性能が出た。
 * つまり単体で最大性能発揮しようと思ったらＧｂＥは足りないかもしれないけど、１０ＧｂＥ埋めるのは結構大変。
 * ましてや「複数台が同時に」という確率と合わせると数台程度ならＧｂＥでも余裕。
 * まぁアレだ。キャパシティプランニングで、動画再生のような常時帯域を使いまくるような前提は勘弁な。

=== パケットフィルタリング無しで ===
ipfw/pf/iptables/tcpwrapper といったパケットフィルタリングを行わない。

 * ＮＦＳｖ４に絞ってるので制限しやすくなってるが、専用ネットワークならそれほどの必要性を感じない。
 * 不特定多数の人が使うような用途で、ＮＦＳクライアントの偽装やら root 権限奪取やら、あるいはそれに準じるようなアクセスがあることを想定しているなら、Kerberos 認証とか IEEE 802.1X（認証ＶＬＡＮ）とか IEEE 802.1AE（MACsec）とか導入した方がいいと思うの（言ってることの現実性はテキトー）。

=== 認証や暗号化・アクセス制御は無しで ===
認証？何それ。ＵＮＩＸアカウント一択（デフォルトの -sec=sys）で。

 * ＮＦＳクライアントとＮＦＳサーバーでのファイル所有者の取り扱いは可能な限りシームレスで、つまり、root は root として扱う（違うと色々面倒なんだよ）。
 * Kerberos は Kerberos で大変なんだよ。 orz
 * 通信の暗号化？ちょっ（ｒｙ。
   * Kerberos 有効にしないとアカンって。
   * IPsec？パケットは暗号化されるけど、ＮＦＳクライアントで tcpdump(8) したらバレるよねぇ。
   * あぁ。ＶＰＮ越しなら IPsec もアリか。
 * SELinux の類い。
   * 自分アレ、コントロール（ステップアップ）できないので、disabled の扱いで。 

=== 結論 ===
とりあえず少しずつステップアップすることがぢゅーよー、ということで、この手順を参考に難しいことに挑戦してみてください。