LinuxのNFSセキュリティ設定入門｜エクスポート制限・NFSv4移行・ファイアウォール連携で共有ストレージを堅牢化する実践ガイド

「NFSの設定、とりあえず動けばいいでしょ」——そう思って運用しているサーバーが、社内で最もセキュリティ上の弱点になっている場合があります。

NFS（Network File System）は、Linuxサーバー間でディレクトリをネットワーク越しに共有するプロトコルです。しかし、デフォルト設定のまま放置すると、内部ネットワーク上にいる誰でもファイルシステムをマウントし、任意のファイルを読み書きできてしまうケースがあります。

この記事では、NFSが抱えるセキュリティリスクと現場で即使える対策手順を解説します。/etc/exportsの安全な書き方から、NFSv4への移行、ファイアウォール設定、Kerberos認証連携まで網羅します。

NFSとは？なぜセキュリティ対策が重要なのか

NFS（Network File System）は、1984年にSunが開発したネットワークファイル共有プロトコルで、現在もLinuxのファイルサーバー、開発環境の共有ストレージ、コンテナ基盤のPersistent Volumeとして広く使われています。

NFSが特にセキュリティ上の注意を要する理由は、その設計思想にあります。NFSは「同一の信頼できるネットワーク内での共有」を前提としており、初期バージョン（v2・v3）では認証の仕組みがほぼ存在しません。

AUTH_SYS（旧称AUTH_UNIX）と呼ばれるデフォルトの認証方式は、クライアントが申告するUID（ユーザーID）とGID（グループID）をそのまま信用します。つまり、クライアント側で任意のUIDを名乗ることができ、そのUID/GIDに対応するファイルへのアクセスが通ってしまいます。

内部ネットワークが「信頼できる」という前提が崩れた現代——リモートワーク、BYOD（私物端末の持ち込み）、横断侵害の手口が一般化した今——では、NFSを対策なしで動かし続けることはリスクそのものです。

攻撃者が悪用するNFSの弱点（敵を知る）

防御の前に、攻撃者がNFSをどう悪用するかを整理します。

【弱点1】認証なしでのマウント

/etc/exportsに *(rw) や 192.168.0.0/16(rw) と広すぎる範囲を書いていると、そのネットワーク上の任意のホストがNFSサーバーに接続し、対象ディレクトリをマウントできます。パスワードも鍵も不要です。

内部ネットワークに侵害済みの端末が1台でもあれば、そこから一気にファイルサーバーの中身にアクセスできることを意味します。

【弱点2】UID/GIDなりすまし

NFSv3以前のAUTH_SYS認証では、クライアントが「UID=1001としてアクセスする」と宣言するだけです。クライアント側でroot権限があれば任意のUIDを指定できます。サーバー上のUID 1001が機密ファイルの所有者であれば、そのファイルを自由に読み取られます。

【弱点3】no_root_squashの設定ミス

NFSはデフォルトで root_squash が有効になっており、クライアントからrootとしてアクセスしても、サーバー側では nobody として扱われます。しかし管理者が利便性のために no_root_squash を設定すると、クライアントのrootがサーバー上でもrootとして振る舞えてしまいます。

本番サーバーに no_root_squash が設定されているケースは、侵害後の被害拡大の温床になります。

【弱点4】通信の平文（NFSv3以前）

NFSv3以前は通信内容が平文です。同一ネットワーク上でパケットキャプチャを実施されれば、転送中のファイル内容を読み取れます。機密情報を含む共有領域では特に危険です。

具体的な防御手順

1. /etc/exportsの堅牢化

まず現在のエクスポート設定を確認します。

# 現在のエクスポート設定を確認する
cat /etc/exports

# 実際に有効なエクスポートを表示する
exportfs -v

設定を見直す際の基本原則です。

・IPアドレスを明示指定する: *（全ホスト）は使用禁止。アクセスを許可するIPアドレスまたはサブネットを明示します
・最小権限でエクスポートする: 読み取りのみ必要なら ro（読み取り専用）を使用します
・root_squashを維持する: no_root_squash は特別な理由がない限り設定しません
・syncオプションを使う: async はパフォーマンス優先でデータ消失リスクがあるため、本番環境では sync を推奨します

悪い設定例と良い設定例を比較します。

# NG例: 全ホスト・書き込み許可・no_root_squash（危険）
/data *(rw,no_root_squash)

# OK例: 特定サブネット・読み取り専用・root_squashあり
/data 192.168.10.0/24(ro,sync,root_squash,no_subtree_check)

# OK例: 特定の1台にのみ書き込みを許可する場合
/srv/shared 192.168.10.50(rw,sync,root_squash,no_subtree_check)

設定変更後は反映が必要です。

# エクスポート設定を再読み込みする
sudo exportfs -ra

# 変更が反映されているか確認する
sudo exportfs -v

2. NFSv4への移行とv2/v3の無効化

NFSv4はv3と比較してセキュリティが大幅に向上しています。主な改善点です。

・Kerberos認証への対応: krb5（認証のみ）・krb5i（+整合性検証）・krb5p（+通信暗号化）が選択可能
・IDマッピング機能: UID/GIDの数値ではなく「ユーザー名@ドメイン」形式で認証するため、なりすましが困難
・ファイアウォールフレンドリー: TCP/2049のみを使用。v3はrpcbind等の複数ポートが必要で管理が複雑

NFSv2とv3を無効化するには、/etc/nfs.conf を編集します。

# /etc/nfs.conf を編集してv4のみ有効化する
# [nfsd] セクションに追記する

[nfsd]
vers2=n
vers3=n
vers4=y

# 変更後にNFSサーバーを再起動する
sudo systemctl restart nfs-server

# v4のみ有効になっているか確認する（-が無効、+が有効）
cat /proc/fs/nfsd/versions
# 期待する出力例: -2 -3 +4 +4.1 +4.2

クライアント側でもNFSv4でマウントするよう明示します。

# NFSv4.2を明示してマウントする
sudo mount -t nfs4 -o vers=4.2 192.168.10.100:/srv/shared /mnt/shared

# /etc/fstab への記載例（永続マウント）
192.168.10.100:/srv/shared  /mnt/shared  nfs4  vers=4.2,rw,_netdev  0  0

3. firewalldでNFSポートを制限する

NFSv4はTCP/2049のみを使用するため、ファイアウォール設定がシンプルになります。アクセス元を特定のサブネットに限定します。

# 特定のサブネットからのみNFSアクセスを許可する
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.10.0/24" service name="nfs" accept'

# 設定を反映する
sudo firewall-cmd --reload

# 設定されたリッチルールを確認する
sudo firewall-cmd --list-rich-rules

NFSv3を使わざるを得ない場合は、rpcbind（ポート111）、mountd、statd、lockdなど複数のサービスポートを制御する必要があります。NFSv4への移行がファイアウォール管理を格段に簡素化してくれます。

4. Kerberos認証（krb5）との連携

組織内にActive DirectoryやKDC（Key Distribution Center）が存在する場合、NFSv4とKerberosを組み合わせることで強力な認証を実現できます。

Kerberos連携のセキュリティレベルには3種類あります。

・sec=krb5: Kerberosによる認証のみ（通信内容は平文）
・sec=krb5i: 認証 + メッセージ整合性検証（改ざん検知）
・sec=krb5p: 認証 + 整合性検証 + 通信の暗号化（最も安全）

/etc/exportsでKerberosセキュリティフレーバーを指定します。

# /etc/exports への設定例（暗号化+整合性検証）
/srv/secure 192.168.10.0/24(rw,sync,sec=krb5p,root_squash,no_subtree_check)

# 利用可能な暗号化アルゴリズムを確認する
cat /proc/fs/nfsd/supported_krb5_enctypes

Kerberos連携には、サーバーとクライアント双方でのKerberosレルム設定（/etc/krb5.conf）とサービスプリンシパルの取得が必要であり、実装難易度はやや高いです。まずは前述の手順1～3を実施してから、段階的に導入することをおすすめします。

中小企業でも今日からできること

Kerberos導入が難しい環境でも、次の3点だけで攻撃リスクを大幅に下げることができます。

・/etc/exportsを確認し、*とno_root_squashを排除する（所要15分）: これが最優先。不特定ホストからの書き込みを即座にブロックできます
・NFSv4への移行とv2/v3の無効化（所要1時間）: /proc/fs/nfsd/versionsで現状を確認し、v2・v3を無効化します。移行前に既存クライアントのマウント状況を先に確認してください
・firewalldでアクセス元を絞り込む（所要30分）: NFSサーバーへのアクセスを特定のサブネットまたはホストに限定します

アクセスログの記録も重要です。NFSサーバーのsyslogを集中ログサーバーに転送しておくと、侵害後の証跡調査に役立ちます。Linuxのrsyslogリモートログ転送設定と組み合わせた運用を検討してください。

よくある誤解と注意点

【誤解1】「内部ネットワークだから安全」

NFSの脅威の多くは内部ネットワーク経由です。マルウェア感染端末、侵害された別のサーバー、悪意ある内部関係者——すべてが「内部ネットワーク」にいます。ファイアウォールと/etc/exportsの両方でアクセス元を厳格に絞り込む必要があります。

【誤解2】「root_squashがあれば安全」

root_squashはクライアントのrootユーザーをnobodyにマッピングするだけです。UID 1001のユーザーが機密ファイルの所有者であれば、クライアント側でUID 1001を名乗るだけでそのファイルにアクセスできます。完全な認証にはKerberos連携が必要です。

【誤解3】「NFSv4にすれば通信が暗号化される」

NFSv4単体では通信は暗号化されません。暗号化には sec=krb5p オプション（Kerberos連携）が必要です。Kerberosを導入できない場合は、NFSをVPN経由（WireGuard等）でラップする方法もあります。

【注意】no_subtree_checkの選択

subtree_checkはエクスポートディレクトリのサブツリーチェックを有効にしますが、ファイルのリネームや移動が発生するとクライアントがStaleエラーを返す問題があります。現在のLinuxカーネルでは no_subtree_check がデフォルトで推奨されています。ルート（/）全体をエクスポートしない限り、no_subtree_check を使うのが一般的です。

本記事のまとめ

NFSはデフォルト設定のままでは、内部ネットワーク上の誰でもファイルシステムをマウントできる状態になりがちです。今すぐ実施すべき対策を優先度順にまとめます。

Linuxサーバーの初期セキュリティ設定全体については、Linuxサーバー初期セキュリティ設定チェックリストもあわせてご覧ください。

NFSの共有ディレクトリ内のアクセス権限をさらに細かく制御するには、Linux ACL（setfacl・getfacl）入門の活用もおすすめです。

LinuxのSSHやファイルシステム権限の詳細については、姉妹サイトLinuxMaster.JPでも解説しています。