chrootでnamed（bind）を実行することがセキュリティ上非常に重要なのはなぜですか？それともそうではないのですか？

私はバインドで遊んでいると、このソフトウェアが、たとえば、chrootで実行されているCentOSにある理由を疑問に思い始めました。私を誤解しないでください、私はバインドが何であり、chroot（jail）が何であるかを知っています。しかし、私の主な質問は、chrootなしでバインドを実行することは非常に安全ではないということです。

刑務所なしでセットアップすることは本当に有害ですか（他のサービスやソフトウェアよりも）。システムでは、chrootなしで実行されている多くのプロセスがあり、それらのいずれかの侵害は非常に危険だと思いますが、chrootなしで実行されている他のソフトウェアよりもnamedがより危険なのはなぜですか？

@Some Guyが言ったように、歴史的な観点からこれについて考えなければなりません。

歴史的な見方では、単一のハードウェアは、単一のオペレーティングシステムの下では数十個の異なるサービスでした。1つのサービスが侵害された場合、そのハードウェア上のすべてが侵害されました。

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

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

以前のバージョンのバインドでは、特権は削除されませんでした。Unixでは、ルートアカウントのみが1024未満のポートを開くことができ、バインドはudp / 53およびtcp / 53でリッスンする必要があることを知っています。Bindはルートとして起動し、特権を落とさないため、システム全体が侵害される可能性があります。最近のほとんどのソフトウェアは、ソケットを開き、root権限を必要とする他の処理を開始し、実行しているユーザーを非特権アカウントに変更します。特権が削除されると、侵害されることによる影響はホストシステムよりもはるかに低くなります。

他の答えはかなり良いですが、レイヤーのセキュリティの概念については言及していません。システムに追加するセキュリティのすべてのレイヤーは、敵が克服しなければならない別のレイヤーです。BINDをchrootに入れると、もう1つの障害が追加されます。

BINDに悪用可能な脆弱性があり、誰かが任意のコードを実行できるとしましょう。彼らがchrootにいる場合、システム内の他の何かに到達する前に、それらを抜け出す必要があります。前述のように、chrootを解除するにはルート権限が必要です。BINDはルートとして実行されません。chrootには最小限のツールがあり、オプションをさらに制限し、本質的にはシステムコールのみを残します。特権をエスカレートするシステムコールがない場合、攻撃者はDNSレコードを見て立ち往生しています。

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

前文

私は人々がインターネット中からの誤解を繰り返し聞くのを聞き続けます。したがって、私はいくつかの明確化を試みます

最初に; 偶然の発見が何件ありましたか。単に原因と結果のために、意図した目的以外のものに使用されることになりましたか？

Chroot刑務所とは何ですか

Chrootは当初、プロセスまたはユーザーのルートディレクトリを変更するように設計されました（未知のソースからソフトウェアをコンパイルするのに最適です）。これにより、ベースシステムにセキュリティが提供され、簡単なクリーンアップを含む迅速なテストベッドアプライアンスが提供されました。それから数年が経ちましたが、その概念と暗黙の使用法は確かに変わっています。

chrootが使用されている効果とのためのコードベースに直接であり、いくつかのプログラムやライブラリ（すなわちopenSSHd、apache2の+ mod_security2 / mod_chroot、Dovecotは、sendmailの、OpenVPNの、pam_chroot、およびそんなに多く）。これらすべての主流のアプリケーションが欠陥のあるセキュリティソリューションを実装していると仮定するのは正しくありません

chrootは、ファイルシステムの仮想化のソリューションです。chrootから簡単に抜け出すことができるという仮定も真実ではありません... chroot刑務所内でプロセスを実行するガイドラインに従う限り。

chroot刑務所を保護するためのいくつかの手順

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

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

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

前述のとおり、chrootはファイルシステムの仮想化を提供します。setuid実行可能ファイル、安全でないアプリケーション、ライブラリ、所有者のいないシンボリックリンクなどが存在しないことを確認する必要があります。他の方法で、chroot内にある何かを危険にさらします。通常は、特権のエスカレーションによって、またはベースシステムにペイロードを注入することによって、刑務所をエスケープします。

これが発生した場合、通常は不正な更新、ゼロデイ攻撃、または慣用的な人為的エラーの結果です。

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

このシナリオを考慮してください。ホストノードがOpenVZを実行している仮想プライベートサーバーを実行しています。単にカーネルレベルで動作するものを実行することはできません。これは、オペレーティングシステムの仮想化を使用してプロセスを分離できず、追加のセキュリティを提供できないことも意味します。このように、あなたがしなければならない。この目的のためにchrootを使用しています。

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

別のシナリオを検討してください。仮想化環境内でApacheを実行しています。各ユーザーを分離する必要があります。Apacheへのchrootアドオン（mod_chroot、mod_securityなど）を介して仮想化ファイルシステムを提供することは、エンドユーザー間の最大限のプライバシーを確​​保するための最良のオプションです。これは、Intelの収集を防ぐのにも役立ち、さらに別のセキュリティ層を提供します。

簡単に言えば、セキュリティをレイヤーに実装することが重要です。Chrootは潜在的にそれらの1つです。すべてのシステムやすべてのシステムがカーネルにアクセスできるわけではないため、chroot STILLには目的があります。システム全体の仮想化が本質的に過剰であるさまざまなアプリケーションがあります。

あなたの質問に答えて

私は特にCentOSを使用しませんが、Bindは操作の前にその特権をドロップすることを知っています。ただし、攻撃ベクトルの履歴と潜在的な脆弱性のため、バインドがchrootされていると想定します。

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

オペレーティングシステムプロバイダーは、すべてのユーザーが同じシステムを実行していると仮定して単純に回避することはありません。このように、彼らは一般的にセキュリティの追加層を提供するのに役立ちます...

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

これは、古いバージョンのBindに深刻で頻繁なセキュリティ脆弱性があったという歴史的な理由が部分的に原因です。私はこのテーマについて最新の情報を提供していませんが、悪い時代からずっと改善されていると思います。

もう1つの理由は、より実用的な理由ですが、通常はインターネットに直接接続する役割で展開されているため、より多くの攻撃、調査、および一般的ないたずらにさらされています。

したがって、多くの場合、セキュリティ問題の経験則であるように、申し訳ありませんが、特にchrootを実行する労力が比較的少ないため、より安全です。