このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。

NFS

NFS ファイル共有システムは、良い意味でも悪い意味でも「古い」。UNIX 系 OS にはほぼ必ず実装されているので、LINUX マシン同士でファイルを簡単にやりとりすることができる。しかし一方、メールの SMTP プロトコルのように、他人 (他PC) が信じられる時代の性善説で成り立っているプロトコルである点は否めず、セキュリティを確保しながら利用するのは難しい。出来る限りのセキュリティ対策を施し、ローカルネットワーク内のみでの使用に限定し、使う時だけ起動させる姿勢で用いるべきだ。

※ 当ページは NFSv4 が使い物になる前、主に nfs-utils 1.0.4 での検証を元に書いたものだ。NFSv4 については、もっと最近別ページにまとめた。

NFS の動作に関係するデーモン

RedHat 系の RPM パッケージでは、portmap だけは portmap パッケージ、それ以外は nfs-utils パッケージに含まれる。下表のセルの色分けは、RedHat 系 ディストリビューションで、どの rc スクリプトで起動されるかを示す。 NFS に関係する rc スクリプトとして、この他に netfs もあるが、それはログイン時に勝手に /etc/fstab を読んで samba や NFS タイプのファイルシステムを自動的にマウントするためのものであり、その都度手動マウントする場合にはサーバ側にもクライアント側にも必要なく、セキュリティ面からも停止が推奨されている。

• 黄色■： /etc/init.d/portmap
• 青色■： /etc/init.d/nfs
• 橙色■： /etc/init.d/nfslock

実行ファイル名/hosts_access名/RPCサービス名 対応表

サーバ主設定ファイル /etc/exports

書式：

directory client(option,option...) client(option,option...) ...

各パラメータの詳細：

directory:

開放するディレクトリを指定

client:

マウントを許可するクライアント。指定方法はいくつかある：

1. ホスト名か FQDN (例： somemachine, somemachine.hoge.cxm, あるいはワイルドカードを利用して *.hoge.cxm)
2. ネットグループ (例： @somegroup)
3. IP範囲 (例： 192.168.1.1-15 なら 192.168.1.0/255.255.255.240 または 192.168.1.0/28)。ワイルドカード併用不可

3. の指定方法を推奨する。その際には、「内部サブネットに属するアドレスは外部から入ってくるはずがない」 というポリシーをファイヤーウォールやルータに設定しておくと、安全性がさらに高まる。当家 iptalbes設定例 (特に bad_input チェーン) 参照。

option:

上記client部と、オプションの `(' との間にスペースを入れてはいけないことに注意。

ro	読み取り専用で共有。デフォルト
rw	読み書き可能で共有
sync async	遅延書き込みを有効にするか。遅延書き込みを有効 (async) にしておくと、サーバ上で実際に sync が行われる前にサーバがリブートした場合データが壊れる恐れがある。NFS-1.1 以上では sync がデフォルト
root_squash no_root_squash	root_squash を直訳すれば「root 権限つぶし」。クライアントから UID 0 としてのファイル操作要求を受けた際、権限を剥奪し、nobody なユーザにマッピングする。デフォルトは root_squash 有効。下記 anonuid, anongid によってマッピング先 UID/GID が指定できる
all_squash no_all_squash	上記の拡大版で、 root に限らず全てのユーザが特定の 1ユーザにマッピングされる。デフォルトでは no_all_squash つまり無効。マッピング先 UID/GID は下記 anonuid, anongid で指定できる
anonuid=xxx anongid=xxx	上記の squash を行う際のマッピング先ユーザを指定したい場合に使用。 ID は文字列呼称でなくナンバーで指定しなければならない。つまり、マッピング先ユーザ/グループは、サーバとクライアントとで同一の UIDナンバー/GIDナンバー、同一の文字列呼称を持っていないと、おかしなことになる。指定しない場合のデフォルトは、nobody, nobody (RedHat系パッケージの場合は nfsnobody, nfsnobody)

設定例：

/home/hoge 192.168.1.0/28(ro,sync)

NFS 起動後に主設定ファイルを書き換えた場合は、 exportfs -ra コマンドを発行すれば変更が反映される。

メモ

Solarisでは /etc/dfs/dfstab ファイルに下記のような塩梅で書く。 `root=' は Linux の場合の no_root_squash にあたる。

share -F nfs -o root=client1:client2,rw=client1:client2,ro=client3 /home/hoge

反映するには shareall または shareall -F nfs あるいは

root# /etc/init.d/nfs.server stop
root# /etc/init.d/nfs.server start

クライアント側の設定

単純に一時的にマウントするなら、例えばサーバ hoge の /home/hoge を /mnt/export にマウントする場合、クライアント上で：

root# mount -t nfs hoge:/home/hoge /mnt/export

とコマンドすれば良い。しかし、より最適なオプションを指定してクライアントの /etc/fstab に書いておくのが賢明。エントリは：

hoge:/home/hoge /mnt/export nfs ro,nosuid,_netdev,noauto,rsize=8192,wsize=8192,hard,intr,nfsvers=3,mountvers=3,notcp 0 0

主なマウントオプションの意味：

セキュリティ

意図したクライアント以外からアクセスされないよう、サーバに制限を設ける。上層では TCP Wrappers による規制を掛け、さらにもっと手前で iptables (ファイヤーウォール) によるパケットフィルタを掛ける。

TCP Wrappers による規制

TCP ラッパーは tcpd が司る TCP/UDP のアクセス制限フィルタ。xinetd 経由で起動されるサービス、あるいは libwrap (/usr/lib/libwrap.a) をサポートしているサービスならば、 /etc/hosts.allow (許可するホストのリスト) と /etc/hosts.deny (拒否するホストのリスト) によってアクセスを規制できる。 TCP ラッパーをおおよそ理解したいのなら Red Hat ドキュメントサイト にある (例えば) Red Hat Enterprise Linux 3 の「リファレンスガイド」 tar ボールに含まれる ch-tcpwrappers.html が役に立つだろう。

実行バイナリが libwrap.a にリンクされているかどうかは、下記のコマンドで調べられる (nfsd の例)：

strings /usr/sbin/rpc.nfsd |grep hosts

上記の試験によると、Fedora Core 1 に関しては、NFS関連デーモンの内、portmap と rquotad だけしか libwrap に対応していないようだが、付属の man を読んでみると、その他に少なくとも rpc.mountd と rpc.statd は TCP Wrappers をサポートしていることになっている。しかしともかく、関連サービスすべてを TCP ラッパーに掛けておくことにする。ホストアクセス設定ファイルに記述するサービス名は実行ファイルの名前とは異なる点に注意。実行ファイル名/hosts_access名/RPCサービス名対応表 参照。記述法については `man 5 hosts_access' してみると良い。

/etc/hosts.deny (拒否ホストリスト)

まず、こちらの設定ファイルで、すべてのホストからのアクセスを拒否する。

portmap mountd statd nfsd lockd rquotad: ALL

/etc/hosts.allow (許可ホストリスト)

必要なホスト (クライアント) からの接続を許可する。192.168.1.1-15 からのアクセスを受け入れる場合：

portmap mountd statd nfsd lockd rquotad: 192.168.1.0/255.255.255.240

規制がちゃんと効いているかどうかは、相手側でデーモン群を起動しておき、クライアントから以下のコマンドを発行すれば分かる。 host の部分は相手のホスト名に置き換えるべし。ちなみに、host 引数を指定しないと localhost が対象となる：

root# rcpinfo -p host

または、UDP パケットを送って反応を調べるコマンド。こちらは引数省略不可：

root# rcpinfo -u host service

で状態を詳細表示してみる。 service の部分はこれまた実行ファイル名ともホストアクセスのサービス名とも違い、rpcinfo -p で表示される名称でなくてはならない。例えば lockd であれば nlockmgr を指定するといった具合。

iptables による規制

iptables によるパケットフィルタは、その要求がどのプロセス (TCP Wrappers も含めて) に渡されるよりも前に行われるので、まさに水際での防御となる。

パケットフィルタリングのための準備

NFS サービスをファイヤーウォールでフィルタリングするには、少々厄介な問題がある。 デフォルトでは、portmap と nfsd 以外の NFS 関連デーモンは、使用するポートが動的に変化してしまうのだ。そこで、まず、それらのデーモンのポートを固定する必要がある。

mountd, rquotad, statd のポート固定

mountd, rquotad, statd の 3 つは、デーモン起動時にオプションパラメータを渡すことで固定が可能だ。なお、RedHat 系では /etc/sysconfig/nfs に特定の変数を設定しておくことによって、rc スクリプトが読み取ってくれるようになっている。以下にその変数名も示す：

また、 NFS デーモン群はデフォルトでは TCP と UDP の両方で待機するが、 mountd に関しては、オプションによって UDP でのみ待機するように指示することができる。多くのNFSクライアントは、マウント要求にデフォルトでは UDP を使うので、多種多様なOSやディストリビューションから成る大クライアント群を相手にしなければならない場合を除いては、TCP 待機は無効にしてしまっても構わないようだ。 rpc.mountd に渡すオプションは --no-tcp 。 RedHat 系ならば sysconfig/nfs に：

RPCMOUNTDOPTS="--no-tcp"

を書き加えておけば、この変数が rc スクリプトに拾われ、 rpc.mountd のオプションパラメータとして渡される。

lockd のポート固定

他のプログラムとは異なり、lockd はカーネルモジュールなので、オプションを直接渡す仕掛けを持たない。その代わり /etc/modules.conf にモジュールオプションとして書いておくのが標準的な手段。あるいは、/etc/sysctl.conf に書いておくという手法もある。ただし RedHat 系では、init.d/nfs の中で、 sysctl コマンドを使ってカーネルパラメータを直接設定するルーティンが組まれており、やはり /etc/sysconfig/nfs に変数として書いておけば設定できる。

modules.conf に書いておく場合の記述：

options lockd nlm_udpport=xxxx nlm_tcpport=xxxx

sysctl.conf に書いておく場合の記述：

fs.nfs.nlm_udpport = xxxx
fs.nfs.nlm_tcpport = xxxx

RedHat 系の rc スクリプト変数 (/etc/sysconfig/nfsで設定)：

意図通りになったか確認

root# service nfs rstart
root# rpcinfo -p

フィルタリングルール

最低限、許可しなければならないポートは以下。下記の例では、 portmap を除いては、mound も nfsd も UDP のみ使用する前提に立っている。
まずは汎用的なルール記述例を挙げることにしよう。

INPUT chain

OUTPUT chain

当家 iptables 「インターネットサーバの自己防衛」 に倣った設定例

Iptables の設定例を記載した当家「インターネットサーバの自己防衛」に NFS サーバを追加する場合の例を示す。

tcp_packets chain (INPUT の子チェーン)

# {1-3-7} tcp_packets chain rules
-A tcp_packets -p tcp -m multiport --dports 80,110,25,22,443 -j allowed
-A tcp_packets -p tcp -s 192.168.1.0/28 --dport 111 -j allowed
-A tcp_packets -p tcp -i eth0 -j ms_packets_tcp

udp_packets chain (INPUT の子チェーン)

# {1-3-8} udp_packets chain rules
-A udp_packets -p udp -s 192.168.1.0/24 --dport 123 -j ACCEPT
-A udp_packets -p udp -s 192.168.1.0/28 --dport 111 -j ACCEPT
-A udp_packets -p udp -s 192.168.1.0/28 --dport 2049 -j ACCEPT
-A udp_packets -p udp -s 192.168.1.0/28 --dport 32765:32766 -j ACCEPT
-A udp_packets -p udp -s 192.168.1.0/28 --dport 32768 -j ACCEPT
-A udp_packets -p udp -i eth0 --dport 67:68 -j DROP
-A udp_packets -p udp -i eth0 -j ms_packets_udp

OUTPUT chain

OUTPUT パケットに関しては、ローカル発のパケットかどうか確認してから基本的には全部許可しているので、追加のルールは特に必要ない。とはいえ、より厳重にしたい場合は OUTPUT チェーンに以下のようなルールを加えてもいいだろう。なお、最初にあるローカル to ローカルのパケットを許可するルールは、NFS デーモン群のスタート/ストップ時に portmap がそうしたパケットを出すので必要となる。

# {1-3-C} OUTPUT chain rules
-A OUTPUT -p all -d 127.0.0.1 -s 127.0.0.1 -j ACCEPT
-A OUTPUT -p tcp -d ! 192.168.1.0/28 --sport 111 -j DROP
-A OUTPUT -p udp -d ! 192.168.1.0/28 --sport 111 -j DROP
-A OUTPUT -p tcp -d ! 192.168.1.0/28 --sport 2049 -j DROP
-A OUTPUT -p udp -d ! 192.168.1.0/28 --sport 2049 -j DROP
-A OUTPUT -p tcp -d ! 192.168.1.0/28 --sport 32765:32768 -j DROP
-A OUTPUT -p udp -d ! 192.168.1.0/28 --sport 32765:32768 -j DROP
-A OUTPUT -p all -s 127.0.0.1 -j ACCEPT 
-A OUTPUT -p all -s 192.168.1.1 -j ACCEPT
-A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level info --log-prefix "IPT OUTPUT packs died: "
 COMMIT

チューニング

パフォーマンス以前の問題なのだが、マウントは出来るが存在するはずのファイルが読めない、`server not responding' が多発する、といった場合には、まず第一に、NFS-HOWTO の Optimizing NFS Performance (NFSの性能を最適化する) の章をありがたく御拝読すること。その中からつまみ食いで、筆者が体験的に得た戒めや功を奏した項目を並べると...

• クライアントの rsize や wsize を 8192 に上げたりすると、確かにリードスピードやライトスピードが目に見えて速くなるが、NFS over UDP の場合にはパケットが盛大にフラグメント化し、かえってパケットロスが増えて使い物にならなくなることがある。特に、サーバとクライアントのスピードが非対称な場合に深刻。ジャンボフレームを有効にしていない限りイーサネットの MTU が 1500 バイトであることを忘れるな。
• 現代の平均的なパワーのマシンにおいては、nfsd の通信にステートフルな TCP を使った時のオーバーヘッドは、ステートレスなプロトコルである UDP を使った時に比べてさほど重荷とはならないようだ。 NFS over TCP をはなから毛嫌いしないほうがいい。
• たくさんの要求を受け付けなければならない NFS サーバの場合、nfsd のプロセス数を増加させると良い。プロセス数は nfsd の起動コマンドの引数として `/usr/sbin/rpc.nfsd 16' のように与えるが、 RedHat系の場合には /etc/sysconfig/nfs ファイルに RPCNFSDCOUNT=16 のように変数定義することで nfs起動スクリプトに読み取らせることができる。RedHat系を含むほとんどのディストリビューションでのデフォルトは 8本。

要求キューバッファの拡大

Optimizing NFS Performance では、上に紹介した以外にも、クライアントからの要求をバッファするための、サーバのメモリ割り当てを増やすというアプローチが紹介されている。筆者は前述のパラメータと同時に試したため、これが純粋にどの程度の効果を発揮したかは定かでないが、加減さえ誤らなければ、少なくともマイナスに働くことはないはずだ。

具体的な方法としては；

1. /proc/sys/net/core/ の rmem_default, rmem_max, wmem_default, wmem_max に値をセットする。
2. nfsd を起動する。
3. 他の動作に害を及ぼさないよう、上の4つの値をすかさずデフォルトに戻す。

という手順だが、これをいちいち手動でやるのは現実的でない。そこで、 RedHatの /etc/init.d/nfs に少々手を加え、そいつがデフォルトで使うパラメータファイル /etc/sysconfig/nfs でキューメモリの値もセットできるようにしたのが、下のツールだ。適法方法を示す；

1. nfsmemtune ファイルを /usr/local/sbin/ へコピーする。これは /etc/init.d/nfs のインクルードファイルとして働き、2種類の引数を採るひとつのシェルファンクション qmemtune() を提供する。 -tune 引数で呼ばれると、前述の行程 1 にあたることを行い、現在の (r|w)mem_* のデフォルト値をテンポラリファイルへ記録してから希望の値を proc へセットする。 -restore 引数で呼ぶと今度は、テンポラリファイルを読んで proc を常態へと書き戻し、テンポラリファイルを削除する。
2. /etc/init.d/nfs に変更を加える。パッチにもしておいた (nfs_memtune.diff) ので、
   patch -d /etc/init.d < /PATH/TO/nfs_memtune.diff
   で適用できる。これまでのところ RedHat EL4 と Fedora Core 3 でテスト済み。だが、パッチが当たらなかったとしても、なぁに、変更箇所は極小、手編集でも事足りる。この下が編集箇所の全てだ。
   1. まず start) ケース分岐の最上部に、インクルードファイルの読み込みと -tune 引数での呼び出しを書く；

      if [ -f /usr/local/sbin/nfsmemtune ]; then
          . /usr/local/sbin/nfsmemtune
          qmemtune -tune
      fi

   2. もう一箇所は、同じく start) ケース分岐の、末尾 (;;の上) に書き加える下記のコマンド。 $QMEMTUNE は qmemtune -tune の処理の中で設定される変数なので、 4つの変数のうちいずれも設定されなかったか nfsmemtune ファイルそのものが存在しない場合 -resotre は実行されない。

      [ -n "$QMEMTUNE" ] && qmemtune -restore

3. /etc/sysconfig/nfs ファイルに以下の変数を追加する。単位はバイト。デフォルト値に任せたいものは、右辺を空にするか、はなから書かなければよい。ここでは *mem_default を 512Kバイトに、 *mem_max を 1Mバイトに設定している。

   RMEM_DEFAULT=524288
   RMEM_MAX=1048576
   WMEM_DEFAULT=524288
   WMEM_MAX=1048576

4. root# service nfs start あるいは restart