chroot で named(bind) を実行することがセキュリティにとってなぜそれほど重要なのでしょうか? あるいは、そうではないのでしょうか?

Question

私は bind をいじっていて、なぜこのソフトウェアが CentOS で chroot で実行されているのか疑問に思い始めました。誤解しないでください。bind と chroot (jail) の目的が何であるかは知っています。しかし、私の主な疑問は、bind が chroot なしで実行されると、それほど安全ではないのかということです。

jail なしでセットアップするのは本当に有害でしょうか (他のサービスやソフトウェアよりも)。システムでは chroot なしで実行されるプロセスが多数あり、それらのいずれかが侵害されると非常に危険だと思いますが、named が chroot なしで実行される他のソフトウェアよりも危険なのはなぜでしょうか?

Answer 1

@Some Guy が述べたように、これについては歴史的な観点から考える必要があります。

歴史的には、単一のハードウェアは単一のオペレーティング システムの下で 12 個程度の異なるサービスで構成されていました。1 つのサービスが侵害されると、そのハードウェア上のすべてが侵害されます。

仮想化では、この問題ははるかに少なくなります。VM から脱出することは不可能ではありませんが、決して簡単ではありません。VM から脱出することは、ルート権限で実行されているプロセスが chroot から脱出することよりも確かに困難です。そのため、私のバインド サーバーは独自の VM で実行されています。その場合、VM であるという事実だけで損害がすでに制限されているため、chroot にはあまり意味がありません。

chroot は、VM のようなものを作成するための非常に弱い試みです。ただし、chroot は、root 権限を持つプロセスによってエスケープできます。chroot はセキュリティ メカニズムとして意図されておらず、機能しません。BSD jail または LXC を使用した chroot は、OS レベルの仮想化を提供し、セキュリティ機能を提供します。しかし、今日では、マシン全体の新しい VM を起動するのが非常に簡単なので、この目的のためにセットアップしたり、OS レベルの仮想化ツールの使用方法を学習したりする労力は価値がないかもしれません。

以前のバージョンの bind では権限が削除されませんでした。Unix では、1024 未満のポートを開くことができるのは root アカウントのみで、Bind は udp/53 と tcp/53 をリッスンする必要があることは周知のとおりです。Bind は root として起動し、権限が削除されないため、侵害が発生するとシステム全体が侵害される可能性があります。最近のほとんどのソフトウェアは、ソケットを開いて root 権限を必要とするその他の操作を実行すると、実行しているユーザーを非特権アカウントに変更します。権限が削除されると、侵害によるホスト システムへの影響は大幅に軽減されます。

Answer 2

他の回答もかなり良いのですが、セキュリティの階層化という概念について触れられていません。システムに追加するセキュリティの階層は、攻撃者が克服しなければならない別の階層です。BIND を chroot に配置すると、さらに 1 つの障害が追加されます。

たとえば、BIND に悪用可能な脆弱性があり、誰かが任意のコードを実行できるとします。chroot 内にいる場合、システムの他の部分にアクセスする前に、chroot から抜け出す必要があります。前述のように、chroot を突破するには root 権限が必要です。BIND は root として実行されず、chroot で使用できるツールは最小限であるため、オプションがさらに制限され、基本的にシステム コールのみが残ります。権限を昇格するシステム コールがない場合、攻撃者は DNS レコードを調べるしかありません。

SomeGuy が述べているように、前述の状況はややありそうにありません。BIND には現在、脆弱性がほとんどなく、リモート実行ではなく DoS タイプのシナリオに限定されています。とはいえ、chroot での実行は多くの OS のデフォルト構成であるため、セキュリティをわずかに強化するためにユーザー側で努力する必要はほとんどありません。

Answer 3

前文

インターネット上で人々が誤解を繰り返しているのを聞き続けているので、私はいくつかの説明をしてみようと思います。

最初に;偶然の発見はどれだけあっただろうか。原因と結果、何かに使われてしまった他の本来の目的よりも？

クロウト監獄とは何か、そして現在とは何か

Chrootは当初、プロセスまたはユーザーのルートディレクトリを変更するために設計されました（未知のソースからのソフトウェアをコンパイルするのに最適）。これにより、安全ベース システムだけでなく、簡単なクリーンアップを含む簡単なテスト ベッド アプライアンスにも追加されました。それから何年も経ち、そのコンセプトと暗黙の用途も同様に確実に変化しました。

chrootが使用されている効果的に、コードベースに直接組み込まれています。いくつかのプログラムとライブラリ（openSSHd、apache2 + mod_security2/mod_chroot、dovecot、sendmail、openVPN、pam_chrootなど）その他多数）。これらの主流のアプリケーションが欠陥のあるセキュリティソリューションを実装していると仮定するのは、違います

chroot はファイル システムの仮想化に対するソリューションです。それ以上でもそれ以下でもありません。chroot 監獄内でプロセスを実行するというガイドラインに従っている限り、chroot から簡単に抜け出せるという仮定も正しくありません。

chroot jail を安全にするための手順

つまりないプロセスをROOTとして実行します。これにより、ルートエスカレーションベクトルが開かれる可能性があります（これはchrootの内外でも当てはまります）。プロセスを実行しないでください。内部chroot、別のプロセスと同じユーザーを使用する外chroot。攻撃対象領域を制限し、プライバシーを確​​保するために、各プロセスとユーザーを独自の Chroot に分離します。必要なファイル、ライブラリ、デバイスのみをマウントします。最後に、chroot は基本システム セキュリティの代替ではありません。システム全体を保護します。

もう一つの重要な注意点:多くの人は、OpenVZ は壊れている、または完全なシステム仮想化と比較すると同等ではないと考えています。彼らがこのように考えるのは、OpenVZ が本質的には Chroot であり、プロセス テーブルが滅菌されており、ハードウェアとデバイスにセキュリティ対策が施されているからです。ほとんどこれらは chroot 内で実装できます。

すべての管理者が、専用サーバーまたは完全なシステム仮想化環境において必要なカーネル パラメータをすべて保護するために必要なレベルの知識を持っているわけではありません。つまり、OpenVZ を導入すると、顧客がアプリケーションを導入する前にカバーして保護しようとする攻撃対象領域が大幅に減少します。優れたホストはこれらのパラメータを適切に保護します。その結果、ノードまたはデータ センターの全員だけでなく、インターネット全体にとっても良い結果をもたらします...

前述のとおり、chroot はファイル システムの仮想化を提供します。setuid 実行ファイル、安全でないアプリケーション、ライブラリ、所有者のない未接続のシンボリック リンクなどがないことを確認する必要があります。攻撃者が bind を侵害できる場合、バッファ オーバーランを起こす何か、ファイル記述子を操作する何か、または chroot 内に存在する何かを侵害する何か (通常は特権のエスカレーションによって jail から脱出するか、基本システムにペイロードを挿入する) を仮想ファイル システムで探す必要があります。

このようなことが起こる場合、通常は不正なアップデート、ゼロデイ攻撃、または慣用的なヒューマンエラー。

完全なシステム仮想化ではなく、chroot がまだ使用されている理由

このシナリオを考えてみましょう。仮想プライベートサーバーを運用しており、ホストノードではOpenVZが稼働しています。できないカーネルレベルで動作するものはすべて実行できます。これは、オペレーティングシステムの仮想化を使用してプロセスを分離したり、追加のセキュリティを提供したりできないことも意味します。したがって、しなければならないこの目的には chroot を使用します。

さらに、chroot は、利用可能なリソースに関係なく、どのシステムでも持続可能です。簡単に言えば、どの仮想化タイプよりもオーバーヘッドが最小限です。つまり、多くのローエンド ボックスでは依然として重要です。

別のシナリオを考えてみましょう。仮想化環境内で Apache を実行しています。各ユーザーを分離したいと考えています。Apache の chroot アドオン (mod_chroot、mod_security など) を介して仮想化ファイル システムを提供することが、エンド ユーザー間のプライバシーを最大限に確保するための最善のオプションです。これは情報収集の防止にも役立ち、さらに別のセキュリティ レイヤーを提供します。

簡単に言えば、セキュリティを実装することが重要ですレイヤーchrootは潜在的にその1つです。すべての人やすべてのシステムがカーネルにアクセスできるという贅沢があるわけではないので、chrootまだ目的を果たします。完全なシステム仮想化が本質的に過剰であるアプリケーションは多数あります。

あなたの質問にお答えします

私は特に CentOS を使用しているわけではありませんが、Bind が操作前に権限を削除するようになったことは知っています。ただし、攻撃ベクトルと潜在的な脆弱性の履歴があるため、bind は chroot されていると想定しています。

また、誰もが完全なシステム/オペレーティング システム レベルの仮想化にアクセスできるわけではないため、このアプリケーションを自動的に chroot する方が、そうしないよりも理にかなっています。これにより、理論上は CentOS ユーザー ベースにセキュリティが提供されます。

オペレーティング システム プロバイダーは、すべてのユーザーが同じシステムを実行していると想定しているわけではありません。このようにして、プロバイダーは広範囲にわたるセキュリティの追加レイヤーの提供に貢献できます...

理由がある多くのアプリケーションでこれが使用されています明らかに OS がデフォルトでこれを実行する理由は、これがセキュリティ機能として使用されており、実際に機能するからです。前述のように、慎重に準備すれば、これは潜在的な攻撃者が克服しなければならないもう 1 つのハードルになります。ほとんどの場合、被害は chroot jail のみに制限されます。

Answer 4

これは、Bind の古いバージョンに深刻なセキュリティ上の脆弱性が頻繁に存在していたという歴史的な理由によるところが大きいです。私はこの件についてあまり詳しくありませんが、古き悪かった時代から比べればかなり改善されていると思います。

もう 1 つの理由は、より実用的なもので、通常はインターネットに面した役割で展開されるため、より多くの攻撃、調査、および一般的な悪意に対して無防備であるということです。

したがって、セキュリティ問題でよくある経験則として、安全第一が原則です。特に、chroot 化の労力は比較的少ないため、安全第一が原則です。