<sect1 id="security">
<!--O
 <title>Security and NFS</title>
-->
 <title>セキュリティと NFS</title>
 <para>
<!--O
   This list of security tips and explanations will not make your site 
   completely secure. <emphasis>NOTHING</emphasis> will make your site completely secure. Reading this section
   may help you get an idea of the security problems with NFS. This is not 
   a comprehensive guide and it will always be undergoing changes. If you 
   have any tips or hints to give us please send them to the HOWTO 
   maintainer.
-->
   ここでいくつかセキュリティ上の留意点を述べますが、
   これであなたのサイトが完全に安全になるわけではありません。
   なにものも、サイトを<emphasis>完全に</emphasis>安全にすることはできません。
   この節を読めば
   NFS 絡みのセキュリティ問題に関する知識を得る助けにはなるでしょうが、
   網羅的なガイドではありませんし、この内容も常に変化し続けています。
   もしセキュリティ関連の技やヒントをお持ちでしたら、
   HOWTO の管理者に送ってください。
 </para>
 <para>
<!--O
   If you are on a network with no access to the outside world (not even a 
   modem) and you trust all the internal machines and all your users then 
   this section will be of no use to you.  However, its our belief that 
   there are relatively few networks in this situation so we would suggest 
   reading this section thoroughly for anyone setting up NFS.
-->
   もしあなたのネットワークが、外部といっさいの通信を行わず
   (モデムもだめ)、かつ内部のマシンすべてとユーザすべてを信頼できるなら、
   この節の内容はあなたの役には立ちません。
   しかしこのような状況にあるネットワークはどちらかというと少数でしょうから、
   NFS を設定する人には、この節を徹底的に熟読することをおすすめします。
 </para>
 <para>
<!--O
   With NFS, there are two steps required for a client to gain access to 
   a file contained in a remote directory on the server. The first step is mount
   access. Mount access is achieved by the client machine attempting to 
   attach to the server. The security for this is provided by the 
   <filename>/etc/exports</filename> file. This file lists the names or IP addresses for machines
   that are allowed to access a share point. If the client's ip address 
   matches one of the entries in the access list then it will be allowed to
   mount. This is not terribly secure. If someone is capable of spoofing or
   taking over a trusted address then they can access your mount points. To
   give a real-world example of this type of "authentication": This is 
   equivalent to someone introducing themselves to you and you believing they
   are who they claim to be because they are wearing a sticker that says
   "Hello, My Name is ...."  Once the machine has mounted a volume, its
   operating system will have access to all files on the volume (with the
   possible exception of those owned by root; see below) and write access
   to those files as well, if the volume was exported with the 
   <userinput>rw</userinput> option.
-->
   NFS において、サーバのリモートディレクトリにあるファイルへ
   アクセスできるようになるためには、
   クライアントは 2 つの段階を経なければなりません。
   最初の段階はマウントアクセスです。
   マウントアクセスは、サーバにアタッチしようとしている
   クライアントマシンによって行われます。
   この段階でのセキュリティは
   <filename>/etc/exports</filename> ファイルが左右します。
   このファイルは、共有ポイントへのアクセスを許可するマシンの
   名前または IP アドレスをリストしたものです。
   クライアントの IP アドレスがこのアクセスリストのエントリのどれかに
   マッチすれば、そのマシンはマウントを許されます。
   これはものすごく安全、というわけではありません。
   アドレスを詐称されたり乗っ取られたりすると、
   マウントポイントへのアクセスを許してしまいます。
   このタイプの「認証」を実世界に例えてみましょうか:
   誰かが自己紹介をしてきたとして、
   その人に「こんにちは、私の名前は○○です」
   という名札がついていることを理由に、
   その自己紹介の内容を信じるようなものです。
   マシンがボリュームをマウントすると、そのマシンで動作している
   OS は、そのボリュームのすべてのファイルにアクセスできることになります
   (root が保有しているファイルは除外可能。後述)。
   そのボリュームが <userinput>rw</userinput>
   オプションつきでエクスポートされていれば、
   これらのファイルへの書き込みアクセスも可能となります。
 </para>
 <para>
<!--O
   The second step is file access. This is a function of normal file system
   access controls on the client and not a specialized function of NFS. 
   Once the drive is mounted the user and group permissions on the files
   determine access control. 
-->
   二番目の段階はファイルアクセスです。
   これはクライアントにおける、
   通常のファイルシステムのアクセス制御機能であり、
   NFS 独自のものではありません。
   ドライブがマウントされると、
   そこのファイルのユーザパーミッション・グループパーミッションが
   アクセス制御を決めることになります。
 </para>
 <para>
<!--O
   An example: bob on the server maps to the UserID 9999. Bob
   makes a file on the server that is only accessible the user 
   (the equivalent to typing 
   <userinput>chmod 600</userinput> <emphasis>filename</emphasis>).
   A client is allowed to mount the drive where the file is stored.
   On the client mary maps to UserID 9999. This means that the client
   user mary can access bob's file that is marked as only accessible by him.
   It gets worse: If someone has become superuser on the client machine they can
   <command>su - </command> <emphasis>username</emphasis> 
   and become <emphasis>any</emphasis> user. NFS will be none the wiser. 
-->
   再び例を: bob はサーバでユーザ ID 9999 にマップされているとしましょう。
   ボブはサーバでユーザのみがアクセスできるファイル
   を作ります (<userinput>chmod 600</userinput> <emphasis>filename</emphasis>
   と入力するのと同じです)。
   そのファイルが保存されたドライブへのアクセスを、
   あるクライアントが許可されました。
   そのクライアントでは、ユーザ ID 9999 には mary がマップされています。
   この場合、bob が自分にしかアクセスできないようにしたファイルに対して、
   そのクライアントでのユーザ mary がアクセスできてしまいます。
   さらに悪いことに、そのクライアントで誰かがスーパーユーザになってしまうと、
   その誰かは <command>su - </command> <emphasis>username</emphasis>
   によって <emphasis>どんな</emphasis> ユーザにもなれてしまうのです。
    NFS は賢いとは言えません。
 </para>
 <para>
<!--O
   Its not all terrible. There are a few measures you can take on the server
   to offset the danger of the clients. We will cover those shortly.
-->
<!--nakano It's -->
   これは絶望的な状況というわけではありません。
   このクライアントによる危険性は、
   サーバにいくつかの手段を施せば軽減することができます。
   それらも簡単に紹介します。
 </para>
 <para>
<!--O
   If you don't think the security measures apply to you, you're probably
   wrong. In <xref linkend="portmapper-security"> we'll cover securing the portmapper, 
   server and client security in <xref linkend="server.security"> and <xref linkend="client.security"> respectively. 
   Finally, in <xref linkend="firewalls"> we'll briefly talk about proper firewalling for
   your nfs server. 
-->
   セキュリティ問題は自分には関係ない、という考えはおそらく間違いです。
   <xref linkend="portmapper-security">
   ではポートマッパを安全にする方法を述べ、
   <xref linkend="server.security"> ではサーバを、
   <xref linkend="client.security"> ではクライアントを安全にする方法を
   それぞれ説明します。
   最後に <xref linkend="firewalls"> で、
   NFS サーバ向けの正しいファイアウォール設定について
   簡単に議論したいと思います。
 </para>
 <para>
<!--O
   Finally, it is critical that all of your nfs daemons and client programs
   are current. If you think that a flaw is too recently announced for it to
   be a problem for you, then you've probably already been compromised.
-->
   最後にもう一つ、
   nfs のデーモンとクライアントプログラムのすべてを最新にしておくことは
   非常に重要です。ごく最近にアナウンスされた問題だから
   自分には関係ないだろう、という考えている人は、
   すでにその時点で侵入されているかもしれませんよ。
 </para>
 <para>
<!--O
   A good way to keep up to date on security alerts is to subscribe to the 
   bugtraq mailinglists.  You can read up on how to subscribe and various 
   other information about bugtraq here:   

  <ulink url="http://www.securityfocus.com/forums/bugtraq/faq.html">http://www.securityfocus.com/forums/bugtraq/faq.html</ulink>
-->
   最新のセキュリティ勧告を逃さないようにするには、
   bugtraq メーリングリストを購読するのが良いでしょう。
   購読の方法など、bugtraq に関する各種の情報は
  <ulink url="http://www.securityfocus.com/forums/bugtraq/faq.html">http://www.securityfocus.com/forums/bugtraq/faq.html</ulink>
   にあります。
 </para>
 <para>
<!--O
   Additionally searching for <emphasis>NFS</emphasis> at 
   <ulink url="http://www.securityfocus.com">securityfocus.com's</ulink> search engine will
   show you all security reports pertaining to NFS.
-->
   また
   <ulink url="http://www.securityfocus.com">securityfocus.com</ulink>
   の検索エンジンで <emphasis>NFS</emphasis> を検索すれば、
   NFS に関連するセキュリティ報告のすべてを見ることもできます。
 </para>
 <para>
<!--O
  You should also regularly check CERT advisories.  See the CERT web page
  at <ulink url="http://www.cert.org">www.cert.org</ulink>.
-->
  CERT の勧告も定期的にチェックしましょう。
  <ulink url="http://www.cert.org">www.cert.org</ulink>
  にある CERT のウェブページをご覧になってください。
 </para>
 <sect2 id="portmapper-security">
<!--O
  <title>The portmapper</title>
-->
  <title>ポートマッパ</title>
  <para>
<!--O
    The portmapper keeps a list of what services are running on what ports.
    This list is used by a connecting machine to see what ports it wants to
    talk to access certain services. 
-->
    ポートマッパはどのサービスがどのポートで動作しているかの一覧を
    保管します。接続してくるマシンは、
    あるサービスにアクセスするにはどのポートに接続すれば良いかを、
    このリストを用いて知るのです。
  </para>
  <para>  
<!--O
    The portmapper is not in as bad a shape as a few years ago but it is
    still a point of worry for many sys admins.  The portmapper, like NFS and
    NIS, should not really have connections made to it outside of a trusted
    local area network. If you have to expose them to the outside world - 
    be careful and keep up diligent monitoring of those systems.
-->
    ポートマッパは、数年前よりはだいぶましになりましたが、
    しかし現在でも多くのシステム管理者の頭痛の種です。
    ポートマッパも、NFS や NIS と同じく、
    信頼できるローカルエリアネットワークの外からは
    アクセスを許すべきではありません。
    もし外部世界に晒さなければならない環境では、
    常に注意して、これらのシステムを入念に監視しなければなりません。
  </para>
  <para>
<!--O
    Not all Linux distributions were created equal.  Some seemingly up-to-date 
    distributions do not include a securable portmapper. 
    The easy way to check if your portmapper is good or not is to run 
    <emphasis>strings(1)</emphasis> and see if it reads the relevant files, <filename>/etc/hosts.deny</filename> and
    <filename>/etc/hosts.allow</filename>.  Assuming your portmapper is <filename>/sbin/portmap</filename> you can 
    check it with this command: 
-->
    Linux ディストリビューションは、すべて同じにはできていません。
    最新に見えるディストリビューションでも、
    安全でないポートマッパを採用していることがあります。
    現在使っているポートマッパが安全なものかどうかを調べるには、
    <emphasis>strings(1)</emphasis> を用いて、ポートマッパが
    <filename>/etc/hosts.deny</filename> や
    <filename>/etc/hosts.allow</filename>
    といったファイルを見ているか調べることです。
    ポートマッパが <filename>/sbin/portmap</filename>
    にあるのでしたら、次のコマンドでチェックできます:
     <programlisting>
     strings /sbin/portmap | grep hosts.  
     </programlisting>
   </para>
   <para>
<!--O
     On a securable machine it comes up something like this:
-->
     安全なマシンでは、次のような内容が出力されるはずです。
  <screen>
   /etc/hosts.allow
   /etc/hosts.deny
   @(#) hosts_ctl.c 1.4 94/12/28 17:42:27
   @(#) hosts_access.c 1.21 97/02/12 02:13:22
  </screen>
  </para>
  <para>
<!--O
   First we edit <filename>/etc/hosts.deny</filename>.  It should contain the line
-->
  まず <filename>/etc/hosts.deny</filename> を編集します。
  次のような行を含むようにします。
  </para>
  <para>
  <screen>
   portmap: ALL
  </screen>
  </para>
  <para>
<!--O
    which will deny access to everyone.  While it is closed run:
-->
    こうするとあらゆるアクセスを拒否します。
    このクローズした状態で
  <screen>
   rpcinfo -p
  </screen>
<!--O
    just to check that your portmapper really reads and obeys
    this file.  Rpcinfo should give no output, or possibly an error message.
    The files <filename>/etc/hosts.allow</filename> and <filename>/etc/hosts.deny</filename>
    take effect immediately after you save them. No daemon needs to be restarted.
-->
    を実行し、ポートマッパが実際にこのファイルを読み、
    その指定に従っているかを調べてみてください。
    rpcinfo は何の出力も出さないはずです
    (あるいはエラーメッセージを出すかもしれません)。
    <filename>/etc/hosts.allow</filename> および
    <filename>/etc/hosts.deny</filename>
    の各ファイルは、保存すればすぐに反映されます。
    いずれのデーモンも再起動する必要はありません。
  </para>
  <para>
<!--O
    Closing the portmapper for everyone is a bit drastic, so we open it
    again by editing <filename>/etc/hosts.allow</filename>.  But first 
    we need to figure out what to put in it.  It should basically list 
    all machines that should  have access to your portmapper.  On a run of 
    the mill Linux system there are very few machines that need any access 
    for any reason.  The portmapper administers <command>nfsd</command>, 
    <command>mountd</command>, <command>ypbind</command>/<command>ypserv</command>,
    <command>rquotad</command>, <command>lockd</command> (which shows up
    as <computeroutput>nlockmgr</computeroutput>), <command>statd</command>
    (which shows up as <computeroutput>status</computeroutput>) 
    and 'r' services like <command>ruptime</command> 
    and <command>rusers</command>.
    Of these only <command>nfsd</command>, <command>mountd</command>, 
    <command>ypbind</command>/<command>ypserv</command> and perhaps 
    <command>rquotad</command>,<command>lockd</command> 
    and <command>statd</command> are of any consequence.  All machines that need 
    to access services on your machine should be allowed to do that.  Let's 
    say that your machine's address is <emphasis>192.168.0.254</emphasis> and 
    that it lives on the subnet <emphasis>192.168.0.0</emphasis>, and that all 
    machines on the subnet should have access to it (for an overview of those
    terms see the the <ulink url="http://www.linuxdoc.org/HOWTO/Networking-Overview-HOWTO.html">Networking-Overview-HOWTO</ulink>).  Then we write:
-->
    ポートマッパをすべて閉じてしまうのは少々極端に過ぎるので、
    <filename>/etc/hosts.allow</filename> を編集して
    再びオープンしていきましょう。
    しかしまず、このファイルに何を書くか決めなければなりません。
    基本的にはこのポートマッパにアクセスしなければならない
    すべてのマシンをリストします。
    通常の Linux システムを稼働させるにあたっては、
    なんらかの理由で何かのアクセスが必要になるマシンは非常に少ないはずです。
    ポートマッパが管理しているのは <command>nfsd</command>, 
    <command>mountd</command>,
    <command>ypbind</command>/<command>ypserv</command>,
    <command>rquotad</command>,
    <command>lockd</command>
    (<computeroutput>nlockmgr</computeroutput> と表示されます),
    <command>statd</command>
    (<computeroutput>status</computeroutput> と表示されます) など、および
    <command>ruptime</command> や <command>rusers</command>
    のような "r" 系コマンド群です。
    このうちなんらかの重要性があるのは、
    <command>nfsd</command>, <command>mountd</command>, 
    <command>ypbind</command>/<command>ypserv</command> および場合によっては
    <command>rquotad</command>,<command>lockd</command>,
    <command>statd</command> だけでしょう。
    サーバマシンにアクセスが必要なマシンには、
    それを許可してあげる必要があります。
    いまサーバのアドレスが  <emphasis>192.168.0.254</emphasis> で、
    サブネット <emphasis>192.168.0.0</emphasis> につながっているとします。
    そしてそのサブネットのすべてのマシンはサーバにアクセスする必要が
    あるとします (これらの用語の概論としては
    <ulink url="http://www.linuxdoc.org/HOWTO/Networking-Overview-HOWTO.html">Networking-Overview-HOWTO</ulink>
    を見てください。
    <ulink url="http://www.linux.or.jp/JF/JFdocs/Networking-Overview-HOWTO.html">日本語訳</ulink>も JF にあります)。
    この場合は
   <screen>
   portmap: 192.168.0.0/255.255.255.0
   </screen>
<!--O
   in <filename>/etc/hosts.allow</filename>.  If you are not sure what your
   network or netmask are, you can use the <command>ifconfig</command> command to
   determine the netmask and the <command>netstat</command> command to
   determine the network.  For, example, for the 
   device eth0 on the above machine <command>ifconfig</command> should show:
-->
   のような行を <filename>/etc/hosts.allow</filename> に書きます。
   ネットワークとネットマスクがはっきりしない場合は、
   <command>ifconfig</command> コマンドを使えばネットマスクがわかり、
   <command>netstat</command> コマンドを使えばネットワークがわかります。
   例えば、このマシンでデバイス eth0 に
   <command>ifconfig</command> すると、次のようになるはずです。
   </para>
   <para>
   <screen>
   ...
   eth0   Link encap:Ethernet  HWaddr 00:60:8C:96:D5:56
          inet addr:192.168.0.254  Bcast:192.168.0.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:360315 errors:0 dropped:0 overruns:0
          TX packets:179274 errors:0 dropped:0 overruns:0
          Interrupt:10 Base address:0x320
   ...
   </screen>

<!--O
   and <command>netstat -rn</command> should show:

-->
   また <command>netstat -rn</command> は次のようになるはずです。
   <screen>
   Kernel routing table
   Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
   ...
   192.168.0.0     0.0.0.0         255.255.255.0   U     0      0   174412 eth0
   ...
   </screen>
<!--O
   (The network address is in the first column).
-->
   (ネットワークアドレスは最初の列にあります。)
  </para>
  <para>
<!--O
    The <filename>/etc/hosts.deny</filename> and <filename>/etc/hosts.allow</filename> files are 
    described in the manual pages of the same names.
-->
    <filename>/etc/hosts.deny</filename> および
    <filename>/etc/hosts.allow</filename> 各ファイルについては、
    それぞれ同名の man ページで説明されています。
    [訳注: hosts_access(5) の場合が多いと思いますが。]
  </para>
  <para>
   <emphasis>
<!--O
    IMPORTANT: Do not put anything but IP NUMBERS in the portmap lines of
    these files.  Host name lookups can indirectly cause portmap activity
    which will trigger host name lookups which can indirectly cause
    portmap activity which will trigger...
-->
    重要: これらのファイルの portmap の行に、
    IP 番号以外のものを書いてはいけません。
    ホスト名の名前引きは間接的にポートマッパを呼び出すことがあり、
    するとまたホスト名の名前引き生じてポートマッパが呼び出され、
    するとまた...
   </emphasis>
  </para>
  <para>
<!--O
    Versions 0.2.0 and higher of the nfs-utils package also use the 
    <filename>hosts.allow</filename> and <filename>hosts.deny</filename> 
    files, so you should put in entries for <command>lockd</command>, 
    <command>statd</command>, <command>mountd</command>, and 
    <command>rquotad</command> in these files too.  For a complete example,
    see <xref linkend="hosts">.
-->
    バージョン 0.2.0 以降では、nfs-utils パッケージも
    <filename>hosts.allow</filename> と <filename>hosts.deny</filename> 
    の各ファイルを利用します。従ってこれらのファイルには、
    <command>lockd</command>, <command>statd</command>,
    <command>mountd</command>, <command>rquotad</command>
    の各エントリも書いておきましょう。
    詳細な例は <xref linkend="hosts"> を見てください。
  </para>
  <para>
<!--O
    The above things should make your server tighter.  The only remaining
    problem is if someone gains administrative access to one of your trusted
    client machines and is able to send bogus NFS requests.  The next section
    deals with safeguards against this problem. 
-->
    以上の作業によって、サーバはよりしっかりするはずです。
    残りの問題は、信頼したクライアントマシンで誰かが管理者権限を取得し、
    任意の NFS リクエストを送信可能となってしまうような場合です。
    次のセクションでは、この問題に関する安全対策を扱います。
  </para>
 </sect2>
 <sect2 id="server.security">
<!--O
  <title>Server security: nfsd and mountd</title>
-->
  <title>サーバのセキュリティ: nfsd と mountd</title>
  <para>
<!--O
    On the server we can decide that we don't want to trust any requests
    made as root on the client.  We can do that by using the 
    <userinput>root_squash</userinput> option in <filename>/etc/exports</filename>:
-->
    サーバでは、クライアントの root から行なわれたリクエストを
    一切信頼しないようにできます。
    これには <filename>/etc/exports</filename> の指定に
    <userinput>root_squash</userinput> オプションを用います:
   <programlisting>
   /home slave1(rw,root_squash)
   </programlisting>
   </para>
   <para>
<!--O
     This is, in fact, the default. It should always be turned on unless you
     have a <emphasis>very</emphasis> good reason to turn it off. To turn it off use the 
     <userinput>no_root_squash</userinput> option.
-->
     実はこれはデフォルトです。
     無効にすべき、やむにやまれぬ事情がない限り、
     これは常に有効にしておくべきです。
     無効にするには <userinput>no_root_squash</userinput>
     オプションを使います。
   </para>
   <para>
<!--O
     Now, if a user with <emphasis>UID</emphasis> 0 (i.e., root's user ID number) 
     on the client attempts to access (read, write, delete) the file system, 
     the server substitutes the <emphasis>UID</emphasis> of the server's 'nobody' 
     account.  Which means that the root user on the client can't access or 
     change files that only root on the server can access or change.  That's 
     good, and you should  probably use <userinput>root_squash</userinput> on 
     all the file systems you export.  "But the root user on the client can 
     still use <command>su</command> to become any other user and 
     access and change that users files!" say you.  To which the answer is: 
     Yes, and that's the way it is, and has to be with Unix and NFS.  This 
     has one important implication: All important binaries and files should be
     owned by root, and not bin or other non-root account, since the only
     account the clients root user cannot access is the servers root
     account.  In the <emphasis>exports(5)</emphasis> man page there are several other squash 
     options listed so that you can decide to mistrust whomever you (don't) 
     like on the clients.  
-->
    root_squash の状態では、クライアントで <emphasis>UID</emphasis> 0
    (root のユーザ番号) のユーザがファイルにアクセス
    (read, write, delete) しようとすると、
    サーバは <emphasis>UID</emphasis> をサーバにおける 'nobody'
    アカウントのものと置き換えます。
    つまりサーバの root だけにアクセスや変更が許されているファイルに対して、
    クライアントの root がアクセスや変更を行うことができなくなるのです。
    これは良い設定ですので、
    export する全てのファイルシステムに root_squash を用いるべきです。
    「でもクライアントの root ユーザが <command>su</command> を使えば、
    他のユーザになってそのユーザのファイルを変更できちゃうじゃないですか！」
    とあなたはおっしゃるかもしれません。答えは、まさにその通り、
    それが Unix や NFS の流儀なのです。
    これにはひとつ重要な側面があります。
    重要なバイナリやファイルは、すべて root の所有にすべきで、
    bin などの root 以外のアカウントにすべきではありません。
    なぜならクライアントの root ユーザがアクセスできないのは、
    サーバの root アカウントのファイルだけだからです。 
    <emphasis>exports(5)</emphasis> の man ページには、
    他にもいくつか squash (排他) オプションが記述されています。
    これらを用いれば、好きな (あるいは嫌いな)
    クライアントを信頼しないように設定できます。
   </para>
   <para>
<!--O
     The TCP ports 1-1024 are reserved for root's use (and therefore sometimes
     referred to as "secure ports") A non-root user cannot bind these ports.
     Adding the <userinput>secure</userinput> option to an 
     <filename>/etc/exports</filename> means that it will only listed to
     requests coming from ports 1-1024 on the client, so that a malicious
     non-root user on the client cannot come along and open up a spoofed 
     NFS dialogue on a non-reserved port. This option is set by default.
-->
<!--nakano listed to は listen to かなあ-->
     TCP のポート 1〜1024 は root が利用するために予約されており
     (従って "secure ports" と呼ばれることがあります)、
     root でないユーザはこれらのポートにバインドできません。
     <filename>/etc/exports</filename> のエントリに
     <userinput>secure</userinput> オプションを追加すると、
     クライアント側のポート 1-1024 から来た接続要求のみを
     受け付けるようになります。
     こうすると悪意を持った非 root ユーザが、
     偽装 NFS 通信を非特権ポートを使って開くことを防げます。
     このオプションはデフォルトで有効になっています。
   </para>
  </sect2>
 <sect2 id="client.security">
<!--O
  <title>Client Security</title>
-->
  <title>クライアントのセキュリティ</title>
  <sect3 id="nosuid">
<!--O
    <title>The nosuid mount option</title>
-->
    <title>nosuid マウントオプション</title>
    <para>
<!--O
      On the client we can decide that we don't want to trust the server too
      much a couple of ways with options to mount.  For example we can
      forbid suid programs to work off the NFS file system with the 
      <userinput>nosuid</userinput>
      option. Some unix programs, such as passwd, are called "suid" programs: 
      They set the id of the person running them to whomever is the owner of 
      the file. If a file is owned by root and is suid, then the program will
      execute as root, so that they can perform operations (such as writing to
      the password file) that only root is allowed to do. Using the
      <userinput>nosuid</userinput>
      option is a good idea and you should consider using this with all NFS 
      mounted disks.  It means that the server's root user
      cannot make a suid-root 
      program on the file system, log in to the client as a normal user 
      and then use the suid-root program to become root on the client too.  
      One could also forbid execution of files on the mounted file system 
      altogether with the <userinput>noexec</userinput> option.  
      But this is more likely to be impractical than
      <userinput>nosuid</userinput> since a file 
      system is likely to at least contain some scripts or programs that need 
      to be executed.
-->
     クライアント側では、サーバを信頼しすぎないように設定することが可能で、
     これはマウント時のオプションで指定します。
     例えば NFS ファイルシステムにある suid プログラムを
     動作させないようにするには
     <userinput>nosuid</userinput> オプションを使います。
     unix プログラムの中には (例えば passwd)、 "suid"
     プログラムと呼ばれるものがあります。
     これはファイルを実行するユーザ id を、
     そのファイルの所有者と同じにするものです。
     ファイルが root の所有で、かつ suid されていると、
     そのプログラムは root として動作し、
     よって root にしか許されていない操作 (パスワードファイルの書き込みなど)
     がすべて行えてしまいます。
     <userinput>nosuid</userinput> オプションを用いるのはよい考えですから、
     NFS マウントしたディスクすべてに対し、利用を検討してください。
     こうするとサーバの root ユーザが件のファイルシステムに
     suid-root プログラムを作り、クライアントに一般ユーザとしてログインし、
     その suid-root プログラムを使ってクライアントでも root になる、
     ということができなくなります。
     さらに <userinput>noexec</userinput> オプションをつければ、
     マウントしたファイルシステムでのファイルの実行を禁止することもできます。
     しかしファイルシステムには実行すべきスクリプトやプログラムが
     多少なりとも含まれているでしょうから、
     これは <userinput>nosuid</userinput> に比べると
     あまり実用的ではないでしょう。
    </para>
   </sect3>
   <sect3 id="brokensuid">
<!--O
    <title>The broken_suid mount option</title>
-->
    <title>broken_suid マウントオプション</title>
    <para>
<!--O
      Some older programs (<command>xterm</command> being one of them) used to rely on the idea
      that root can write everywhere. This is will break under new kernels on
      NFS mounts.  The security implications are that programs that do this
      type of suid action can potentially be used to change your apparent uid
      on nfs servers doing uid mapping. So the default has been to disable this
     <userinput>broken_suid</userinput> in the linux kernel. 
-->
      古いプログラム (<command>xterm</command> などがそうです) では、
      root はどこにでも書き込み可能である、
      という前提に依存していることがあります。
      これは新しいカーネルと NFS マウントの下では成立しません。
      このような suid 動作を行うプログラムは
      uid の変更に利用できてしまうため、
<!--nakano apparent 難しい-->
      uid マッピングを行う nfs サーバでは
      セキュリティ上問題となります。
      従って linux カーネルのデフォルトでは、
      この <userinput>broken_suid</userinput> は無効になっています。
    </para>
    <para>
<!--O
      The long and short of it is this: If you're using an old linux
      distribution, some sort of old suid program or an older unix of some
      type you <emphasis>might</emphasis> have to mount from your clients with the
      <userinput>broken_suid</userinput> option to <command>mount</command>.  
      However, most recent unixes and linux distros have <command>xterm</command> and such programs 
      just as a normal executable with no suid status, they call programs to do their setuid work.
-->
      かいつまんで言いますと、古い linux ディストリビューションで
      ある種の suid プログラムを使う場合や、
      なんらかの古い unix を使っている場合は、
      マウントの際に
      <command>mount</command> に
      <userinput>broken_suid</userinput>
      オプションを指定する必要があるかもしれません。
      しかし最近の unix や linux ディストリビューションの
      <command>xterm</command> のようなプログラムは、
      suid を必要としない通常の実行ファイルになっていて、
      setuid 動作を行うプログラムを別に呼び出すようになっています。
    </para>
    <para>
<!--O
      You enter the above options in the options column, with the <userinput>rsize</userinput> and
      <userinput>wsize</userinput>, separated by commas.
-->
      これらのオプションは、オプションのカラムに、
      <userinput>rsize</userinput> や
      <userinput>wsize</userinput> などと一緒にコンマで区切って書きます。
    </para>
  </sect3>
  <sect3 id="securing-daemons">
<!--O
   <title>Securing portmapper, rpc.statd, and rpc.lockd on the client</title>
-->
   <title>ポートマッパ、rpc.statd, rpc.lockd をクライアントで安全にする</title>
   <para>
<!--O
     In the current (2.2.18+) implementation of NFS, full file locking is 
     supported. This means that <command>rpc.statd</command> and <command>rpc.lockd</command>
     must be running on the client in order for locks to function correctly. 
     These services require the portmapper to be running. So, most of the 
     problems you will find with nfs on the server you may also be plagued with 
     on the client. Read through the portmapper section above for information on 
     securing the portmapper.
-->
     NFS の現在の (2.2.18 以降) の実装では、
     すべてのファイルロック機能がサポートされています。
     よってクライアントでは、
     <command>rpc.statd</command> と <command>rpc.lockd</command>
     を実行し、ロック機能を正しく動作させる必要があります。
     したがって、これまで nfs のサーバで見てきた問題が、
     そのままクライアントにも当てはまります。
     上記のポートマッパの節をもう一度読んで、
     ポートマッパを安全にするための情報を再確認してください。
   </para>
 </sect3>
 </sect2>
 <sect2 id="firewalls">
<!--O
  <title>NFS and firewalls (ipchains and netfilter)</title>
-->
  <title>NFS とファイアウォール (ipchains と iptables)</title>
  <para>
<!--O
    IPchains (under the 2.2.X kernels) and netfilter (under the 2.4.x 
    kernels) allow a good level of security - instead of relying on the 
    daemon (or  perhaps its TCP wrapper) to 
    determine which machines can connect, 
    the connection attempt is allowed or disallowed at a lower level. In 
    this case, you can stop the connection much earlier and more globally, which
    can protect you from all sorts of attacks.
-->
<!--nakano canstop -->
    IPchains (2.2.x カーネル) と iptables (2.4.x カーネル)
    を用いると、高い安全性を実現できます。
    どのマシンが接続できるかの決定をデーモンに
    (あるいは tcp ラッパーに) 行わせるのではなく、
    接続の試みをより下層で許可/拒否するのです。
    この場合、接続をより早い段階で、またよりグローバルに切断でき、
    あらゆる攻撃からマシンを守ることができるのです。
  </para>
  <para>
<!--O
    Describing how to set up a Linux firewall is well beyond the scope of
    this document. Interested readers may wish to read the <ulink url="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html">Firewall-HOWTO</ulink> 
    or the <ulink url="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.HTML">IPCHAINS-HOWTO</ulink>.
    For users of kernel 2.4 and above you might want to visit the netfilter webpage at: 
    <ulink url="http://netfilter.filewatcher.org">http://netfilter.filewatcher.org</ulink>.
    If you are already familiar with the workings of ipchains or netfilter 
    this section will give you a few tips on how to better setup your 
    NFS daemons to more easily firewall and protect them.
-->
<!--nakano IPCHAINS-HOWTO.HTML -->
<!--nakano netfilter URL is 404-->
<!--nakano 最後の文章は変だ -->
    Linux のファイアウォールをどう設定するかは、
    この文書の範囲を大きく越えています。
    興味を持った読者は
    <ulink url="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html">Firewall-HOWTO</ulink> 
    (JF の <ulink url="http://www.linux.or.jp/JF/JFdocs/Firewall-HOWTO.html">日本語訳</ulink>)
    や
    <ulink url="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html">IPCHAINS-HOWTO</ulink>
    (JF の <ulink url="http://www.linux.or.jp/JF/JFdocs/IPCHAINS-HOWTO.html">日本語訳</ulink>)
    を見てください。カーネル 2.4 以降のユーザは、
    <ulink url="http://netfilter.samba.org">http://netfilter.samba.org</ulink>
    にある netfilter/iptables ウェブページに行ってみてください。
    すでに ipchains や netfilter の動作を熟知している人には、
    この節の内容は NFS デーモンをファイアウォールによってどう守るかについて、
    いくつかのヒントを与えてくれるでしょう。
  </para>
  <para>
<!--O
    A good rule to follow for your firewall configuration is to deny all, and
    allow only some - this helps to keep you from accidentally allowing more 
    than you intended.
-->
    ファイアウォールの設定において従うべきルールは、
    まずすべてを禁止し、少しだけ許可することです。
    こうすれば意図しない許可を間違って通さずにすみます。
  </para>
  <para>
<!--O
 In order to understand how to firewall the NFS daemons, it will help
 to breifly review how they bind to ports.
-->
ファイアウォールよる NFS デーモンの守り方を理解するため、
各デーモンがどのポートを使うかについて見ておくことにしましょう。
</para>
<para>
<!--O
When a daemon starts up, it requests a free port from the portmapper. 
The portmapper gets the port for the daemon and keeps track of 
the port currently used by that daemon. When other hosts or processes
need to communicate with the daemon, they request the port number
from the portmapper in order to find the
daemon. So the ports will perpetually float because different ports may 
be free at different times and so the portmapper will allocate them 
differently each time. This is a pain for setting up a firewall. If 
you never know where the daemons are going to be then you don't 
know precisely which ports to allow access to. This might not be a big deal 
for many people running on a protected or isolated LAN. For those 
people on a public network, though, this is horrible.
-->
デーモンは起動すると、ポートマッパに開いているポートを
割り当ててくれるよう要求します。
ポートマッパはそのデーモンのためにポートを取得し、
そのデーモンがポートを現在使っているかどうか追跡し続けます。
他のホストやプロセスがこのデーモンと通信する必要が生じたときは、
それらはポートマッパに接続に用いるポート番号を尋ねます。
よってポートはずっと浮動 (floating) 状態になります。
いろいろなポートがいろいろなタイミングで解放されるので、
ポートマッパは場合によって別々のポートを割り当てるからです。
これはファイアウォール設定にとっては厄介な問題です。
デーモンの場所がわからなければ、
どのポートにアクセスを許すべきかが正確にはわからないからです。
ほとんどの人にとっては保護された、あるいは隔離された
LAN で作業していますから、これはあまり大きな問題にはならないでしょう。
しかし公開ネットワークにいる人たちにとっては、これは悪夢です。
</para>
<para>
<!--O
In kernels 2.4.13 and later with nfs-utils 0.3.3 or later you no 
longer have to worry about the floating of ports in the portmapper. 
Now all of the daemons pertaining to nfs can be "pinned" to a port. 
Most of them nicely take a <command>-p</command> option when they are started;
those daemons that are started by the kernel take some kernel arguments 
or module options. They are described below.
-->
カーネル 2.4.13 以降と nfs-utils 0.3.3 以降を組み合わせると、
このポートマッパによるポートの浮動を気にする必要はなくなります。
今では NFS に関わるすべてのデーモンは、
ポートを「固定」することができます。
デーモンのほとんどは起動時に行儀良く <userinput>-p</userinput>
オプションを受け付けます。カーネルから起動されるデーモンは、
カーネル引数やモジュールオプションを取ります。
これらは以下で解説します。
</para>
<para>
<!--O
Some of the daemons involved in sharing data via nfs are already 
bound to a port. <command>portmap</command> is always on port 
111 tcp and udp. <command>nfsd</command> is 
always on port 2049 TCP and UDP (however, as of kernel 2.4.17, NFS over
TCP is considered experimental and is not for use on production machines).
-->
NFS でデータ共有を行うためのデーモンのいくつかは、
すでにポートにバインドされています。
<command>portmap</command> は常に tcp と udp のポート 111 を使います。
<command>nfsd</command> は常に tcp と udp のポート 2049 を使います
(しかしカーネル 2.4.17 までは NFS over TCP は実験的とみなされており、
実用のマシンでは用いられていませんでした)。
</para>
<para>
<!--O
The other daemons, <command>statd</command>, <command>mountd</command>,
<command>lockd</command>, and <command>rquotad</command>, will normally move
around to the first available port they are informed of by the portmapper.
-->
他のデーモン、
<command>statd</command>, <command>mountd</command>,
<command>lockd</command>, <command>rquotad</command> は、
ポートマッパから利用できると知らされた最初のポートを利用するので、
ポートはいろいろになります。
</para>
<para>
<!--O
To force <command>statd</command> to bind to a particular port, use the 
<userinput>-p</userinput>
<emphasis>portnum</emphasis> option. To force <command>statd</command> to 
respond on a  particular port, additionally use the 
<userinput>-o</userinput> <emphasis>portnum</emphasis> option when starting it.
-->
<command>statd</command> を特定のポートにバインドさせるには、
<userinput>-p</userinput> <emphasis>portnum</emphasis>
オプションを用います。
<command>statd</command> を特定のポートに反応させるには、さらに起動時に
<userinput>-o</userinput> <emphasis>portnum</emphasis>
オプションを用います。
</para>
<para>
<!--O
To force <command>mountd</command> to bind to a particular port use the 
<userinput>-p</userinput> <emphasis>portnum</emphasis> option.
-->
<command>mountd</command> を特定のポートにバインドさせるには、
<userinput>-p</userinput> <emphasis>portnum</emphasis>
オプションを用います。
</para>
<para>
<!--O
For example, to have statd broadcast of port 32765 and listen on port
32766, and mountd listen on port 32767, you would type:
-->
例えば statd にポート 32765 をブロードキャストさせてポート 32766 で待機させ、
mountd にポート 32767 で待機させるには、次のように入力します。
</para>
<programlisting>
# statd -p 32765 -o 32766
# mountd -p 32767
</programlisting>
<para>
<!--O
<command>lockd</command> is started by the kernel when it is needed. 
Therefore you need 
to pass module options (if you have it built as a module) or kernel 
options to force <command>lockd</command> to listen and respond 
only on certain ports.
-->
<command>lockd</command> は必要に応じてカーネルから起動されます。
よって <command>lockd</command> に特定のポートで待機・反応させるには、
カーネルオプションや
(モジュールとしてビルドされた場合は) モジュールオプションを用います。
</para>
<para>
<!--O
If you are using loadable modules and you would like to specify these
options in your <filename>/etc/modules.conf</filename> file add 
a line like this to the file:
-->
ローダブルモジュールを用いており、
これらのオプションを
<filename>/etc/modules.conf</filename> ファイルで指定するには、
次のような行をこのファイルに追加します。
</para>
<programlisting>
options lockd nlm_udpport=32768 nlm_tcpport=32768
</programlisting>
<para>
<!--O
The above line would specify the udp and tcp port for 
<command>lockd</command> to be 32768.
-->
この指定では、<command>lockd</command> の
udp と tcp のポートを 32768 にします。
</para>
<para>
<!--O
If you are not using loadable modules or if you have compiled 
<command>lockd</command> into the kernel instead of building it
 as a module then you will need to pass it an option on the kernel boot line.
-->
ローダブルモジュールを使わない場合や、
<command>lockd</command> をモジュールとしてビルドせずに
カーネルに組み込んだ場合は、
選んだポートはカーネルのブート時に渡さなければなりません。
</para>
<para>
<!--O
It should look something like this:
-->
次のような感じになります。
</para>
<programlisting>
 vmlinuz 3 root=/dev/hda1 lockd.udpport=32768 lockd.tcpport=32768
</programlisting>
<para>
<!--O
The port numbers do not have to match but it would simply add 
unnecessary confusion if they didn't.
-->
ポート番号は同じにしなくてもかまいませんが、
揃えないと不必要な混乱の原因になってしまうでしょう。
</para>
<para>
<!--O
If you are using quotas and using <command>rpc.quotad</command> to make these 
quotas viewable over nfs you will need to also take it into
account when setting up your firewall. There are two 
<command>rpc.rquotad</command> 
source trees. One of those is maintained in the 
<application>nfs-utils</application> tree. 
The other in the <application>quota-tools</application> tree. 
They do not operate identically. 
The one provided with <application>nfs-utils</application> supports 
binding the daemon to  a port with the <userinput>-p</userinput> 
directive. The one in <application>quota-tools</application> does not. 
Consult your distribution's documentation to determine if yours does. 
-->
quota を使っていて、その情報を nfs 経由でも見せるために
<command>rpc.quotad</command> を使っている場合は、
これもファイアウォールの設定時に考慮しなければなりません。
<command>rpc.rquotad</command> には 2 つのソースツリーがあります。
1 つは <application>nfs-utils</application> で管理されているツリーで、
もう 1 つは <application>quota-utils</application> のツリーです。
これらは同じようには動作しません。
<application>nfs-utils</application> のものは、
<userinput>-p</userinput> で指定すればデーモンをポートにバインドできます。
<application>quota-utils</application> のものはできません。
自分のディストリビューションがどちらを使っているかは、
ディストリビューションの文書にあたってください。
</para>
<para>
<!--O
For the sake of this discussion lets describe a network and setup a 
firewall to protect our nfs server. 
Our nfs server is 192.168.0.42 our client is 192.168.0.45 only.
As in the example above, <command>statd</command> has been 
started so that it only
binds to port 32765 for incoming requests and it must answer on 
port 32766.  <command>mountd</command> is forced to bind to port 32767.
<command>lockd</command>'s module parameters have been set to bind to 32768.
<command>nfsd</command> is, of course, on port 2049 and the portmapper is on port 111.
-->
ここでの議論のために、
ネットワークと NFS サーバを守るためのファイアウォールの設定を見ていきましょう。
私たちの NFS サーバは 192.168.0.42 にあり、
クライアントは 192.168.0.45 のみとします。
上述の例のように、
<command>statd</command> は
入ってくるリクエストについてはポート 32765 のみにバインド、
応答するポートは 32766 を使うとします。
<command>mountd</command> はポート 32767 にバインドします。
<command>lockd</command> のモジュールパラメータは、
32768 にバインドするよう設定します。
もちろん <command>nfsd</command> はポート 2049 を使い、
ポートマッパはポート 111 を使います。
</para>
<para>
<!--O
We are not using quotas.
-->
quota は使わないことにします。
</para>
<para>
<!--O
Using <application>IPCHAINS</application>, a simple firewall 
might look something like this:
-->
<application>IPCHAINS</application> を使った、
簡単なファイアウォール設定は次のようになります。
</para>
<programlisting>
ipchains -A input -f -j ACCEPT -s 192.168.0.45
ipchains -A input -s 192.168.0.45 -d 0/0 32765:32768 -p 6 -j ACCEPT
ipchains -A input -s 192.168.0.45 -d 0/0 32765:32768 -p 17 -j ACCEPT
ipchains -A input -s 192.168.0.45 -d 0/0 2049 -p 17 -j ACCEPT
ipchains -A input -s 192.168.0.45 -d 0/0 2049 -p 6 -j ACCEPT
ipchains -A input -s 192.168.0.45 -d 0/0 111 -p 6 -j ACCEPT
ipchains -A input -s 192.168.0.45 -d 0/0 111 -p 17 -j ACCEPT
ipchains -A input -s 0/0 -d 0/0 -p 6 -j DENY -y -l
ipchains -A input -s 0/0 -d 0/0 -p 17 -j DENY -l
</programlisting>   
<para>
<!--O
The equivalent set of commands in <application>netfilter</application> is:
-->
同じ設定を <application>netfilter</application> で行う場合は次になります。
</para>
<programlisting>
iptables -A INPUT -f -j ACCEPT -s 192.168.0.45
iptables -A INPUT -s 192.168.0.45 -d 0/0 32765:32768 -p 6 -j ACCEPT
iptables -A INPUT -s 192.168.0.45 -d 0/0 32765:32768 -p 17 -j ACCEPT
iptables -A INPUT -s 192.168.0.45 -d 0/0 2049 -p 17 -j ACCEPT
iptables -A INPUT -s 192.168.0.45 -d 0/0 2049 -p 6 -j ACCEPT
iptables -A INPUT -s 192.168.0.45 -d 0/0 111 -p 6 -j ACCEPT
iptables -A INPUT -s 192.168.0.45 -d 0/0 111 -p 17 -j ACCEPT
iptables -A INPUT -s 0/0 -d 0/0 -p 6 -j DENY --syn --log-level 5
iptables -A INPUT -s 0/0 -d 0/0 -p 17 -j DENY --log-level 5
</programlisting>

<para>
<!--O
The first line says to accept all packet fragments (except the 
first packet fragment which will be treated as a normal packet). 
In theory no packet will pass through until it is reassembled, 
and it won't be reassembled unless the first packet fragment 
is passed. Of course there are attacks that can be generated 
by overloading a machine with packet fragments. But NFS won't 
work correctly unless you let fragments through. See <xref linkend="symptom8">
for details.
-->
最初の行ではパケットフラグメントを全て受け付けるようにしています
(ただし先頭のフラグメントは通常のパケットのように扱われます)。
理論的には、あらゆるパケットは再構成されるまでは通過しませんし、
先頭のパケットフラグメントが通過しなければ再構成は不可能です。
もちろんパケットフラグメントを用いて、
マシンを過負荷にしようとする攻撃も存在します。
しかしフラグメントを通すようにしないと、NFS は正しく動作しません。
詳細は <xref linkend="symptom8"> を見てください。
</para>
<para>
<!--O
The other lines allow specific connections from any port on our 
client host to the specific ports we have made available on 
our server.  This means that if, say, 192.158.0.46 attempts to contact 
the NFS server it will not be able to mount or see what mounts 
are available.
-->
他の行は、サーバで利用することにした特定のポートそれぞれへの、
クライアントの任意のポートからの接続を許可しています。
この設定によって、
もし例えば 192.158.0.46 が NFS サーバに接続を試みたとしても、
そのマシンはマウントもできず、
なにがマウントできるかもわからないことになります。
</para>
<para>
<!--O
With the new port pinning capabilities it is obviously much easier
to control what hosts are allowed to mount your NFS shares. It is
worth mentioning that NFS is not an encrypted protocol and anyone
on the same physical network could sniff the traffic and reassemble
the information being passed back and forth.
-->
新たに導入されたポート固定機能を用いれば、
NFS 共有へのマウントを許すホストの制御は見ての通りずっと簡単になります。
ただし NFS は暗号化されたプロトコルではありませんから、
同じ物理ネットワークにつながっていれば、誰でもトラフィックを盗聴し、
行き交う情報を再構成することが可能です。
 </para>
  </sect2>
 <sect2 id="nfs-ssh">
<!--O
  <title>Tunneling NFS through SSH</title>
-->
  <title>NFS に SSH をトンネルさせる</title>
  <para>
<!--O
One method of encrypting NFS traffic over a network is to 
use the port-forwarding capabilities of <command>ssh</command>.
However, as we shall see, doing so has a serious drawback if you do not
utterly and completely trust the local users on your server.
-->
ネットワークの NFS トラフィックを暗号化する方法のひとつとして、
<command>ssh</command> のポートフォワード機能を用いるやり方があります。
しかし、以下で見るように、
サーバのローカルユーザを完全に信頼できない場合は、
これには深刻な欠点もあります。
</para>
<para>
<!--O
The first step will be to export files to the localhost.  For example, to
export the <filename>/home</filename> partition, enter the following into 
<filename>/etc/exports</filename>:
-->
最初のステップは、ファイルをローカルホストにエクスポートすることです。
例えば <filename>/home</filename> パーティションをエクスポートする場合は、
次の行を <filename>/etc/exports</filename> に追加します。
<programlisting>
/home   127.0.0.1(rw)
</programlisting>
</para>
<para>
<!--O
The next step is to use <command>ssh</command> to forward ports.  For example,
<command>ssh</command> can tell the server to forward to any port on any
machine from a port on the client.  Let us assume, as in the previous
section, that our server is 192.168.0.42, and that we have pinned 
<command>mountd</command> to port 32767
using the argument <userinput>-p 32767</userinput>. Then, on the client,
we'll type:
-->
次のステップは <command>ssh</command> を用いてポートをフォワードすることです。
<!--nakaon サーバやらクライアントやらややこしいだけなので cut-->
<command>ssh</command> を使うと、
クライアントの任意のポートを、
任意のマシンの任意のポートにフォワードできます。
例えば前節のように、我々のサーバは 192.168.0.42 とし、
<userinput>-p 32767</userinput> 引数を用いて
<command>mountd</command> をポート 32767 に固定したとしましょう。
そして、クライアントから次のように入力します。
<programlisting>
     # ssh root@192.168.0.42 -L 250:localhost:2049  -f sleep 60m
     # ssh root@192.168.0.42 -L 251:localhost:32767 -f sleep 60m
</programlisting>
</para>
<para>
<!--O
The above command causes <command>ssh</command> on the client to take
any request directed at the client's port 250 and forward it, 
first through <command>sshd</command> on the server, and then on
 to the server's port 2049.  The second line
causes a similar type of forwarding between requests to port 251 on
the client and port 32767 on the server.  The 
<userinput>localhost</userinput> is relative to the server; that is,
the forwarding will be done to the server itself.  The port could otherwise
have been made to forward to any other machine, and the requests would look to
the outside world as if they were coming from the server.  Thus, the requests
will appear to NFSD on the server as if they are coming from the server itself. 
Note that in order to bind to a port below 1024 on the client, we have 
to run this command as root on the client.  Doing this will be necessary 
if we have exported our filesystem with the default 
<userinput>secure</userinput> option.
-->
このコマンドを使うと、クライアントの <command>ssh</command>
はクライアントのポート 250 に対して行なわれたリクエストをフォワードし、
サーバの <command>sshd</command> を経由して、
サーバのポート 2049 へとフォワードします。
次の行もおなじタイプのフォワードで、
クライアントのポート 251 へのリクエストをサーバの 32767 へフォワードします。
<userinput>localhost</userinput> はサーバから見たホストです。
つまり、フォワードはサーバ自身に対してなされます。
これとはべつに、ポートを任意の別のマシンにフォワードすることもでき、
そのリクエストは外世界に向け、
サーバからなされたかのように行われることになります。
よって、このリクエストはサーバの <command>nfsd</command> に対して、
サーバ自身から来たかのように見えます。
ところで、クライアントで 1024 以下のポートをバインドするには、
このコマンドをクライアントの root として実行する必要があります。
ファイルシステムをデフォルトの <userinput>secure</userinput>
オプションでエクスポートした場合には、こうしなければなりません。
</para>
<para>
<!--O
Finally, we are pulling a little trick with the last option,
<userinput>-f sleep 60m</userinput>.  Normally, when
we use <command>ssh</command>, even with the <userinput>-L</userinput> option,
we will open up a shell on the remote machine.  But instead, we just want
the port forwarding to execute in the background so that we get our shell
on the client back.  So, we tell <command>ssh</command> to execute a command
in the background on the server to sleep for 60 minutes.  This will cause
the port to be forwarded for 60 minutes until it gets a connection; at that
point, the port will continue to be forwarded until the connection dies or
until the 60 minutes are up, whichever happens later.  The above command
could be put in our startup scripts on the client, right after the network
is started.
-->
なおここでは、最後のオプション <userinput>-f sleep 60m</userinput>
を用いてちょっとしたトリックを行っています。
普通 <command>ssh</command> を用いると、
<userinput>-L</userinput> オプションを用いた場合でも、
リモートマシンでシェルをオープンすることになります。
しかしここではポートフォワードをバックグラウンドで実行したいだけで、
シェルはクライアントに戻したいわけです。
したがって <command>ssh</command> には、
60 分眠り続けるコマンドをサーバのバックグラウンドで実行させているのです。
これはポートを、接続があるまで 60 分間フォワードします。
接続があると、接続が切れるか 60 分が過ぎるまで、
どちらか遅い方まで接続は継続します。
上記のコマンドは、クライアントの起動スクリプトの
ネットワーク通信開始以降に置くこともできます。
<!--nakano べつに直後でなくてもいいだろ-->
</para>
 <para>
<!--O
  Next, we have to mount the filesystem on the client.  To do this, we tell
  the client to mount a filesystem on the localhost, but at a different
  port from the usual 2049.  Specifically, an entry in <filename>/etc/fstab</filename>
  would look like:
-->
次に、ファイルシステムをクライアントでマウントしなければなりません。
これを行うには、クライアントに対して
localhost のファイルシステムをマウントするように、
ただし通常の 2049 とは違うポートを用いるように、伝えます。
具体的に <filename>/etc/fstab</filename> のエントリを示すと、
次のようになります。
<programlisting>
  localhost:/home  /mnt/home  nfs  rw,hard,intr,port=250,mountport=251  0 0
</programlisting>
</para>
<!--O
<para>Having done this, we can see why the above will be incredibly insecure
if we have <emphasis>any</emphasis> ordinary users who are able to log in
to the server locally.  If they can, there is nothing preventing them from
doing what we did and using <command>ssh</command> to forward a privileged 
port on their own client machine (where they are legitimately root) to ports
2049 and 32767 on the server.  Thus, any ordinary user on the server can
mount our filesystems with the same rights as root on our client.
-->
<para>
ここまで来ると、
サーバのローカルにログインできる通常のユーザがいると、
なぜ非常に危険になってしまうのかが理解できます。
このようなユーザがいると、
我々が行ってきたことを妨げるすべは一切なく、
<command>ssh</command> を用いて
自分のクライアントマシン (ここでは合法的に root になれます)
の特権ポートをサーバのポート 2049 や 32767 にフォワードできます。
このようにして、サーバの任意のユーザは、
我々のクライアントの root と同じ権限で、
任意のファイルシステムをマウントできることになります。
[訳注: 要するに、サーバが localhost に対して
エクスポートすることの危険性を言っています。]
</para>
<para>
<!--O
If you are using an NFS server that does not have a way for ordinary users
to log in, and you wish to use this method, there are two additional caveats:
First, the connection travels from the client to the server via
<command>sshd</command>; therefore you will have to leave port 22 (where
<command>sshd</command> listens) open to your client on the firewall.  However
you do not need to leave the other ports, such as 2049 and 32767, open
anymore.  Second, file locking will no longer work.  It is not possible
to ask <command>statd</command> or the locking manager to make requests
to a particular port for a particular mount; therefore, any locking requests
will cause <command>statd</command> to connect to <command>statd</command>
on localhost, i.e., itself, and it will fail with an error.  Any attempt
to correct this would require a major rewrite of NFS.
-->
NFS サーバで通常のユーザをログインさせておらず、
かつこの方法を使いたい場合でも、
まだ 2 つ、警告しておくことがあります。
まずひとつめ、クライアントからサーバへの接続は
<command>sshd</command> を経由します。
よってファイアウォールで、
ポート 22 (<command>sshd</command> が待機するポート)
をクライアントに対して開けておく必要があります。
しかし、2049 や 32767 のような他のポートを開けておく必要はもうありません。
ふたつめ、ファイルロックが動作しません。
<command>statd</command> やロックマネージャに対して、
特定のマウントに対するリクエストを特定のポートに行なわせることはできません。
したがって、ロックリクエストがあると
<command>statd</command> は localhost の
<command>statd</command> に、つまり自分自身に接続し、
エラーは発生せずに失敗します。
これを修正するためには、NFS を大きく書き換えなければなりません。
</para>
<para>
<!--O
It may also be possible to use <application>IPSec</application> to encrypt
network traffic between your client and your server, without compromising
any local security on the server; this will not be taken up here.
See the <ulink url="http://www.freeswan.org/">FreeS/WAN</ulink> home page
for details on using IPSec under Linux.
-->
<application>IPSec</application> を用いれば、
サーバでのローカルなセキュリティの問題を生じさせない形で
クライアントとサーバ間でのネットワーク通信を暗号化できます。
これはここでは取り上げません。
Linux で IPSec を用いるための詳細については、
<ulink url="http://www.freeswan.org/">FreeS/WAN</ulink>
ホームページを見てください。
</para>
</sect2>
 <sect2 id="summary">
<!--O
  <title>Summary</title>
-->
  <title>まとめ</title>
  <para>
<!--O
    If you use the <filename>hosts.allow</filename>, <filename>hosts.deny</filename>,
   <userinput>root_squash</userinput>, <userinput>nosuid</userinput> and privileged
    port features in the portmapper/NFS software, you avoid many of the
    presently known bugs in NFS and can almost feel secure about that at
    least.  But still, after all that: When an intruder has access to your
    network, s/he can make strange commands appear in your <filename>.forward</filename> or
    read your mail when <filename>/home</filename> or <filename>/var/mail</filename> is 
    NFS exported.  For the same reason, you should never access your PGP private key 
    over NFS. Or at least you should know the risk involved.  And now you know a bit
    of it.
-->
    <filename>hosts.allow</filename>, <filename>hosts.deny</filename>,
    <userinput>root_squash</userinput>, <userinput>nosuid</userinput>,
    特権ポートの機能などをポートマッパや NFS ソフトウェアに用いれば、
    現在 nfs で知られている多くのバグを避けることができ、
    少なくともおおむね安全になったと考えることができるでしょう。
    しかしそれでも結局のところ、侵入者がネットワークにアクセスできてしまえば、
    怪しいコマンドを <filename>.forward</filename> に書いたり、
    <filename>/home</filename> や <filename>/var/mail</filename> が
    NFS エクスポートされていればメールを読んだりできてしまいます。
    また同じ理由から、PGP の秘密鍵は NFS 上に置いてはなりません。
    少なくとも危険性があることは知っておくべきです。
    いまや知ったわけですけど。
  </para>
  <para>
<!--O
    NFS and the portmapper makes up a complex subsystem and therefore it's
    not totally unlikely that new bugs will be discovered, either in the
    basic design or the implementation we use.  There might even be holes
    known now, which someone is abusing.  But that's life.  
-->
    NFS とポートマッパは複雑なシステムになっているので、
    新しいバグが、基本的な設計にせよ我々の用いている実装にせよ、
    将来見つからないとは思えません。
    いまでも新しい穴がわかっていて、
    誰かがそれを悪用しているかもしれません。
    でもそれが人生というものです。
  </para>
 </sect2>
</sect1>

