web-dev-qa-db-ja.com

SSHトンネリングに対するNFSの保護

私はぼんやりと読んでいました http://nfs.sourceforge.net/nfs-howto/ar01s06.html 「6.4。SSHを介したNFSのトンネリング」のセクションに到達したときにローカルホストのエクスポートが悪かった理由を理解しようとしています。他の人がポートフォワードをsshして共有にアクセスできるようにするため、ローカルホストをエクスポートすることはセキュリティ上の脆弱性の可能性があるというそのセクションのすべてが理にかなっています。

これが私の質問です。ユーザーがNFSサーバーに接続できるマシンにSSHで接続できる場合、sshトンネルがシステムのセキュリティを損なうのを防ぐにはどうすればよいですか。たとえば、コンピュータA（192.168.1.1）、B（192.168.1.2）およびC（192.168.1.3）。 Aを次のエクスポートファイルを持つサーバーとします。

/home 192.168.1.2(rw)

ご覧のとおり、AはBに/ home共有の使用を許可しています。ここで、CをBにsshしてみましょう。

$ ssh 192.168.1.2 -L 250:192.168.1.1:2049  -f sleep 60m
$ ssh 192.168.1.2 -L 251:192.168.1.1:32767 -f sleep 60m

BにエクスポートされたAの株式は、BにSSH接続できる人に対して脆弱であるように思われます。これは本当ですか？ Bにログインできる人が非常に信頼できるユーザーであることを確認する以外に、これを防ぐ方法はありますか？

sshssh-tunnelnfs
7
CrazyCasta

これは非常に古いドキュメントで、2001年にリリースされたカーネルバージョン2.4について説明していますが、過去12年間で多くの変更が行われています。いくつかのことは同じままですが。

デフォルトでnfsv4を使用するCentOS6.xボックスしかありません。中間マシンを介した接続を許可するには、insecureを設定してファイルシステムをエクスポートする必要がありました。

したがって、質問に答えるには、nfsv4を使用し、デフォルトのsecureモードを使用します。 Bに十分な特権がある場合は、設定することもできます

AllowTcpForwarding no

/ etc/ssh/sshd_configにあります。

いつものように、あなたが人々に特権を与えるならば、あなたは彼らを信頼しなければなりません。

4
user9517

あなたが強調している問題は欠陥ではなく、機能です！はい、これはSSHプロトコルの機能であり、不適切に構成されたSSHサービスを次のようなさまざまなエクスプロイトに使用できるようにします。

  • ホストファイアウォールのバイパス
  • IP制限をバイパスする
  • 'localhost'インターフェイスでのみリッスンするサービスにリモートアクセスする[mysql？]

一般的な設定ミスとセキュリティ問題の例として、/sbin/nologinシェルをユーザーに設定しても、OpenSSHデーモンのほとんどのデフォルト設定でsshトンネルが生成されるのを防ぐことはできません。

あなたの質問によると、NFSv2/NFSv3を避け、より安全なNFSv4を使用する必要があります。これは、ホストマシンではなく単一のユーザーを認証する別のセキュリティモデルに移行します。または、代わりに、OpenSSHサービスを適切に構成して、通常のユーザーのSSHトンネリングを禁止します。

5
Martino Dino

その文書はかなり古いです（2006年！）。より優れたセキュリティメカニズム（つまり、NFSv4 + GSS）がない場合、エクスポートにホストを追加するということは、そのホスト、そのユーザー、およびプロセスを暗黙的に信頼することを意味します。

SSHポートフォワーディングだけが問題ではありません。許可しないこともできます（sshdの_AllowTcpForwarding no_）が、sshd_config(5)が言うように

TCP転送を無効にしても、ユーザーがシェルアクセスも拒否されない限り、セキュリティは向上しません。ユーザーはいつでも独自のフォワーダーをインストールできるためです。

したがって、リストにsocat、netcat、SOCKS（OpenSSHもサポートしますが、TCPのみ）、OpenSSH tunトンネリングのサポート、さらにはbashを追加します。その_/dev/tcp_サポートとあなたは問題を見ることができます...リストするには多すぎます。

Bにユーザーごとのルールを許可するホストファイアウォールがある場合（つまり、Linux/iptables with _--uid-owner_）、Aがより信頼できるようにBをロックダウンできる可能性があります。それ以外の場合は、GSSとKerberosを使用してNFSv4を試してください。これにより、ユーザーごとの信頼が得られます。

2
mr.spuratic

これは簡単に打ち負かされます

  1. エクスポートがsecureとマークされていることを確認してください
  2. コンピューターCによるコンピューターBへのルートアクセスを許可しない

exports(5)のマニュアルページには次のように書かれています。

secure
This option requires that requests originate on an internet port
less than IPPORT_RESERVED (1024). This option is on by default. 
To turn it off, specify insecure.

これはデフォルトでオンになっていることに注意してください。

コンピューターCからコンピューターBに接続するユーザーは、通常のユーザーとして接続します。説明したようにSSHを介して転送されたNFS接続は、そのユーザーとしてBで実行されているプロセスから発信されたように見えます。これは、接続がBの通常のセキュリティ制御の対象となることを意味します。特に、通常のユーザーは1024未満のポートから接続を開始できません。

私のシステムの1つでテストしたところ、次のことがわかりました。

djs@tuonela:~$ Sudo mount -o port=250,mountport=251,tcp localhost:/srv/users /mnt/x -t nfs
mount.nfs: access denied by server while mounting localhost:/srv/users

もちろん、アカウントをコンピューターBのrootに昇格できる人は誰でもこの保護を無効にすることができるため、NFSクライアントコンピューターを十分にロックダウンする必要があります。

1
Dan