FTPログインユーザーを単一のディレクトリに制限する安全な方法

Question

複数のユーザーにFTPログインを提供する必要がありました。一部は書き込み可能、​​一部は読み取り専用で、単一のFTPルートディレクトリにアクセスできます。私は、彼らがそのディレクトリの上にあるファイルシステムを見ないようにしたかったのです。検索後、これは一般的な問題のようです。user_localconfigオプションをルートディレクトリとして定義し、chroot_local_usersオプションまたはchroot jailを使用してユーザーをそのディレクトリに制限しました。これは基本的に機能します。

私の問題は、なぜだかわかりませんが、セキュリティのためにchroot jailに依存することは、カーネル開発チーム（の少なくとも1人のメンバー）が一般的かつ最も重要なことを嫌うことです。

では、ログインユーザーを、chroot jailなしで定義されたルートディレクトリの上に何も表示されないように制限するにはどうすればよいですか？ （これは、タイトルで言及されている質問の「安全な」部分です）

また、セキュリティ上の理由（私はまだ理解していません）のため、vsftpdの最新バージョンでは、ユーザーのルートディレクトリを書き込み可能にすることができないため、次の2つのオプションがあります。1。またはセキュリティ機能を無効にして、ルート書き込み可能または2.ルートから書き込みビットを削除し、その中に書き込み可能サブディレクトリを作成します。前者は火で遊んでおり、後者は醜くてエラーが発生しやすい（ユーザーがルートに書き込みを試みてエラーが発生する…）私は後者を選択しました。

では、FTPサービスはどのように正しく行われるのでしょうか。つまり、ユーザーがファイルシステムの無関係な部分を安全な方法で見るのを防ぐにはどうすればよいでしょうか。 FTPは本質的に安全でないファイル配布方法ですか？もしそうなら、より良い方法があります。これを正しくしようとしています…

Answer 1

注：このソリューションは私にとってうまく機能し、セットアップも簡単です。 vsFTPdを使用すると仮定します。

私はすべてのユーザーをホームディレクトリに投獄し、「共有」というフォルダをすべてのユーザー間で共有しました。

1. ユーザーを自宅に直接投獄する

   $ Sudo vi /etc/vsftpd/vsftpd.conf
   

   これが次の構成であることを確認してください。

   anonymous_enable=NO
   local_enable=YES
   chroot_local_user=YES
   

   Vsftpdを再起動します。

   $ Sudo service vsftpd restart
   

2. すべてのユーザー用の共有フォルダーを作成し、「ftp」権限を付与します

   $ cd /var/ftp
   $ mkdir shared
   $ chmod 777 shared/
   $ chgrp ftp shared/
   $ chown ftp shared/
   

3. 投獄されたユーザーがその共有フォルダにアクセスできるようにする

   投獄されたユーザーSamの例を見てみましょう。

   あなたが現時点でルートであると仮定します。

   $ su - sam
   $ cd /home/sam
   $ mkdir Shared
   $ exit
   

   これでルートに戻りました。

   $ mount -o bind /var/ftp/shared /home/sam/Shared
   

   Samをftpグループに追加します

   $ usermod -a -G ftp sam
   

   このプロセスを繰り返して、他のユーザーを「共有」フォルダーに追加します。

これで、サムは自分のホームフォルダーにアクセスできるようになり、他のすべてのユーザーにアクセスを許可できる追加の「共有」フォルダーができます。

Answer 2

クライアントがサーバーにファイルをsftpするためのjailedsftpuserを作成した方法は次のとおりです。

1. Sftpgroupを作成します

   # groupadd sftpusers
   

2. Sftpuserを作成します。

   # useradd -g sftpusers -d /incoming/client1 -s /sbin/nologin \
         client1srs passwd client1srs
   

3. ユーザーを変更し、ユーザーをsftp onluyにしてsftp jailに入れます

   # usermod -g sftpusers -d /incoming -s /sbin/nologin client1srs
   

4. Sshd_configにsftp-serverサブシステムをセットアップする

   / etc/ssh/sshd_configを変更し、コメントアウトします。

   # #Subsystem       sftp    /usr/libexec/openssh/sftp-server
   

5. 次に、以下を追加します。

   Subsystem       sftp    internal-sftp
   

6. グループのChrootディレクトリを指定する

   / etc/ssh/sshd_configの最後に次の行を追加します。

   Match Group sftpusers
          ChrootDirectory /sftp/%u
          ForceCommand internal-sftp
   

7. SFTPホームディレクトリを作成する

   # mkdir /sftpdir/client1srs/incoming
   # chown client1srs:sftpusers /sftpdir/client1srs/incoming
   

8. Sshdを再起動します

   # /sbin/service sshd restart
   

Answer 3

この質問はインターネット全体にあり、私が見つけた明確な解決策はありません。

ですから、これが私が今これに立っているところです（詳細がわかり次第更新します）。

基本的な問題は、HTTPクライアントが単にhttpサービスプロセスにリクエストを送信するのではなく、FTPにログインしてファイルシステムを操作していることです。

そのため、FTPユーザーが定期的にログインしている場合、ユーザーがシステム上で実行する権限を持っていることを実行できないように制限することは非常に困難です。 FTPユーザーは、自分の下位レベルのブランチから書き込みまたは読み取りを行えるように、ビューアクセスを制限する場所を超えてディレクトリの実行権限を持っている必要があります。したがって、彼のビューへのアクセスを制限する唯一の簡単な方法は、彼をchroot刑務所に入れることです。

Chroot jailは安全ではありません。それは、「プロセスとその子のパス名ルックアップを変更して、「/」で始まるパスへの参照が新しいルートを実質的に持つことです。これは、単一の引数として渡され、パスの先頭に追加されます」 「現在の作業ディレクトリは変更されず、相対パスは新しいルートの外部のファイルを参照できます。」ソース http://lwn.net/Articles/252794/

これがセキュリティのコンテキストで何を意味するのか、FTPデーモンとユーザー権限に比べてどれほど危険なのかは言えませんが、「chrootjail」の「jail」は誤った名称であることを意味します。

Linuxのディープハンドルでは、プロセスとユーザーの権利を定義することでこのセキュリティコンテキストでchrootを「使用」することが可能であるように見えますが、私もこれに苦しんでいる無数のインターネット居住者もまだ「存在」していません。

Chrootjailを実際にjailのように動作する場所に強化することも可能です-カーネル開発者のAlanCoxの言葉を借りれば、「chrootはセキュリティツールではなく、かつてないものです。人々はchrootのプロパティに基づいて構築しましたが、拡張しました（BSD jail 、Linux vserver）ですが、まったく異なります。LSMモジュールを自分で作成して、これを行うこともできます。」私はまだ「そこにいる」わけではありませんが、結局これが「その」解決策であると私は疑っています。また、ディストリビューションのftpサイトがこれらまたは類似のラインに沿ってセキュリティを処理することも危険です。

実際には、今できることはchroot jailを使用することだけです。サーバーが優先度の低いターゲットであり、ユーザーが基本的に信頼できることを信頼しています。私のセキュリティ戦略は、刑務所から抜け出した場合、被害を制限することです。これには、ユーザー、場合によっては仮想ユーザーを適切に構成し、サービス全体を仮想マシンで実行することが含まれます。

私の研究が進むにつれて、セキュリティのためにLSMなどを介してchroot（）の概念を強化したいと思っています。上記のAlan Coxの引用によると、BSDにはすでに「刑務所」の概念があるので、 FTPのニーズについてBSDを調べるかもしれません。

Answer 4

一般的な答えであれば別の可能性があります（これは間違っている/不可能かもしれませんが、私は本当にフィードバックを望んでいます）：

FTPユーザーのルートとして機能する別のパーティションを作成します。このルートパーティションには、関連するディレクトリしかありません。 ACLを使用して、他のパーティション上のすべてのディレクトリに対するすべてのFTPユーザーの実行権限を削除します。 FTPサーバーを通常のパーティションにインストールして、FTPユーザーのパーティションがプログラムファイルでいっぱいにならないようにします。

このようにして、FTPユーザーには新しいパーティションのルートのみが表示され、選択したとおりにエレガントに構造化できます。

Answer 5

簡単な答え： 必須- または 役割ベース- アクセス制御を使用します。以下のアップデート2を参照してください。

はい、ftpは本質的に安全ではありません。 sftpとscpは、ファイルシステムの一部を非表示にすることに関する問題ではなく、その不安の一部に対処します。たぶんあなたが必要なのはNFSボリュームですか？

vsftpd faq によると、chrootの問題は、ルートファイルシステムになるものをユーザーが読み取り/書き込み制御できることです。

vsftpdは、hide_fileおよびdeny_file設定を提供します。これらの設定を使用して、パターンマッチングを使用して、ファイルを非表示にし、ファイルにアクセスできないようにすることができます。ドキュメントに記載されているように、これらのオプションは「非常にシンプルであり、深刻なアクセス制御には使用しないでください。ファイルシステムの権限を優先して使用する必要があります。」

ユーザーがFTPで何をする必要があるかに応じて、vsftpdのcmds_allowedまたはcmds_deniedを使用してftpユーザーのアクティビティを制限することにより、サイトのセキュリティを強化できる場合があります。

ホストのデータディレクトリをコンテナにマウントして、ftpデーモンinsidea docker コンテナを実行できます。ユーザーにはコンテナ全体が表示されますが、ホストからは何も表示されません。 xinetdを使用して、クライアント接続ごとにdockerizedvsftpdプロセスを生成できる場合があります。次に、コンテナ内のすべてがマウントされたデータボリュームを除いて完全に一時的なものになり、接続が閉じられるとすぐに消えます。

更新：FTPは データ用の個別の接続 転送を使用します。 Docker内でFTPサーバーを実行するには、データ接続をネゴシエートして確立できることを確認する必要があります。これは、 コンテナーの実行 と--net = Hostを使用するか、コンテナーの内部と外部の両方で追加のネットワーク構成を使用することで実行できます。上で提案したようにxinetdを使用してオンデマンドでdockerftpコンテナーを生成するには、そのような構成をコンテナーごとにオンザフライで実行する必要があります。

Update 2：Dockerはセキュリティを保証するものではありません。 エクスプロイトが発見されました 、そしてセキュリティはプロジェクトの主要な目標ではありません。コンテナーを使用して非特権ユーザーとしてftpdを実行するのがおそらく最善でしょう。

実際の解決策は、サーバーのアクセス制御メカニズムを AppArmor 、 SELinux 、または GrSecurity で補完することです。私はそれらのどれでもコンテナ、chroots、または刑務所なしで十分な解決策であるべきだと思います。