なぜchrootでnamed（bind）を実行することがセキュリティ上とても重要なのですか？それともそうではありませんか？
私はbindで遊んでいて、なぜこのソフトウェアがchrootで実行されているCentOSなどにあるのか疑問に思い始めました。誤解しないでください。バインドとは何か、chroot（刑務所）の目的は知っています。しかし、私の主な質問は、chrootなしでバインドを実行することが非常に安全でないということです。
刑務所なしでセットアップするのは本当に有害ですか（他のサービスやソフトウェアよりも）。システムにはchrootなしで実行されるプロセスがたくさんあり、それらのいずれかの侵害は非常に危険だと思いますが、chrootなしで実行される他のソフトウェアよりもnamedの方が危険なのはなぜですか？
@Some Guyが述べたように、これを歴史的な観点から考える必要があります。
歴史的な見方では、単一のハードウェアは、単一のオペレーティングシステムの下での数十の異なるサービスでした。 1つのサービスが侵害された場合、そのハードウェア上のすべてが侵害されました。
仮想化を使用すると、これは問題のはるかに少ないです。 VMから脱出することは不可能ではありませんが、それは簡単なことではありません。VMから脱出することは確かにより困難です。ルート権限で実行されているプロセスがchrootから抜け出します。そのため、私のバインドサーバーは独自のVMで実行されています。その場合、chrootがダメージを受けるのは、 VM。
Chrootは、VMのようなものを作成する非常に弱い試みです。 Chrootは、root権限を持つ任意のプロセスによってエスケープできます。 chrootは意図されておらず、セキュリティメカニズムとして機能しません。 BSD jailを備えたchroot、またはLXCは、OSレベルの仮想化を提供し、セキュリティ機能を提供します。しかし、最近、マシン全体の新しいVM=を起動するのが非常に簡単であるため、セットアップする努力や、この目的でOSレベルの仮想化ツールを使用する方法を学ぶ価値がないかもしれません。
以前のバージョンのbindは特権を落としませんでした。 Unixでは、ルートアカウントだけが1024未満のポートを開くことができ、バインドはudp/53とtcp/53でリッスンする必要があることを誰もが知っているとおりです。 Bindはrootとして起動し、権限を落とさないため、システム全体が侵害される可能性があります。最近のほとんどすべてのソフトウェアは、ソケットを開き始め、root権限を必要とするその他のことを実行し、実行しているユーザーを非特権アカウントに変更します。特権が削除されると、侵害された場合の影響はホストシステムにとってはるかに低くなります。
他の答えはかなり良いですが、レイヤーのセキュリティの概念については言及していません。システムに追加するセキュリティのすべてのレイヤーは、敵が克服しなければならない別のレイヤーです。 BINDをchrootに置くと、もう1つ障害が追加されます。
BINDに悪用可能な脆弱性があり、誰かが任意のコードを実行できるとします。彼らがchrootにいる場合、システム内の他の場所に移動する前に、それを抜け出す必要があります。前述のように、chrootの解除にはroot権限が必要です。 BINDはrootとして実行されず、chrootで使用できる最小限のツールがあり、オプションをさらに制限し、基本的にシステムコールのみを残すことになっています。特権をエスカレートするシステムコールがない場合、攻撃者はDNSレコードを見てスタックしています。
前述の状況は、SomeGuyが言及しているように、ややありそうもありません。BINDの脆弱性は最近ほとんどなく、ほとんどがリモート実行ではなくDoSタイプのシナリオに制限されています。とは言っても、chrootで実行することは、かなりの数のOSのデフォルト構成であるため、セキュリティをこれまでよりもわずかに向上させるために、ユーザーが少しも努力することはほとんどありません。
プリアンブル
私はインターネット全体から人々が誤解を繰り返すのを聞き続けます。したがって、私はいくつかの明確化を試みます
first off;偶発的な発見がいくつあったか-これは単に原因と影響のために何かに使用されてしまいましたotherよりその意図された目的？
Chroot刑務所とは何で、何であるか
Chrootは当初、プロセスまたはユーザーのルートディレクトリを変更するように設計されました（不明なソースからソフトウェアをコンパイルするのに最適です）。これにより、ベースシステムに簡単にクリーンアップできるクイックテストベッドアプライアンスと同様にsecurityが提供されました。それから何年も経ち、その概念と暗黙の使用法も同様に確かに変わりました。
chrootが使用されました実質的に、およびseveralプログラムおよびライブラリのコードベースに直接あります（つまり、openSSHd、Apache2 + mod_security2/mod_chroot、dovecot） 、sendmail、openVPN、pam_chroot、などなど）。これらすべての主流のアプリケーションが不完全なセキュリティソリューションを実装していると仮定すると、単にnot true
chrootは、ファイルシステム仮想化のソリューションです。 chrootから簡単に抜け出すことができるという仮定も当てはまりません... chroot jail内でプロセスを実行するガイドラインに準拠している限りは。
chroot刑務所を保護するためのいくつかの手順
つまり、do [〜＃〜] not [〜＃〜]プロセスをROOTとして実行します。これにより、ルートエスカレーションベクトルが開かれる可能性があります（chrootの内部または外部でも同様です）。プロセスを実行しないinside chroot、別のプロセスと同じユーザーを使用outside chroot。攻撃対象を制限し、プライバシーを提供するために、各プロセスとユーザーを独自のChrootに分離します。必要なファイル、ライブラリ、デバイスのみをマウントします。最後に、chrootは基本システムセキュリティの代わりにはなりません。システム全体を保護します。
別の重要な注記：多くの人々は、OpenVZは壊れている、または完全なシステム仮想化と比較して等しくないと考えています。これは、本質的にChrootであり、滅菌されたプロセステーブルを備えているため、この仮定を行っています。ハードウェアとデバイスにセキュリティ対策が施されています。 mostこのうち、chrootに実装できます。
すべての管理者が、専用サーバーまたは完全なシステム仮想化で必要なすべてのカーネルパラメータを保護するために必要なレベルの知識を持っているわけではありません。これは、OpenVZを展開することで、アプリケーションを展開する前に、顧客が攻撃やカバーを試みて保護する攻撃面がはるかに少なくなることを意味します。優れたホストは、これらのパラメーターを保護する優れた仕事をします。これは、ノードまたはデータセンターのすべての人にとってだけでなく、インターネット全体にとっても優れています...
前述のように、chrootはファイルシステムの仮想化を提供します。 setuid実行可能ファイル、安全でないアプリケーション、ライブラリ、ダングリングオーナーレスシンボリックリンクなどがないことを確認する必要があります。攻撃者がバインドを侵害した場合、オーバーランをバッファリングしたり、ファイル記述子で遊んだりするために仮想ファイルシステムを精査する必要があります。他の何らかの方法で、chroot内にある何かを危険にさらします。通常、特権の昇格またはベースシステムへのペイロードの注入により、刑務所を脱出します。
これが発生した場合、通常は、不正な更新、ゼロデイエクスプロイト、または慣用的な人為的エラーです。
完全なシステム仮想化ではなく、なぜchrootがまだ使用されているのか
このシナリオを検討してください。ホストノードがOpenVZを実行している状態で、仮想プライベートサーバーを実行しています。単純にできないカーネルレベルで機能するものを実行します。これは、オペレーティングシステムの仮想化を使用してプロセスを分離し、セキュリティを強化することもできないことも意味します。したがって、あなたは[〜＃〜] must [〜＃〜]この目的でchrootを使用します。
さらに、chrootは、利用可能なリソースに関係なく、どのシステムでも持続可能です。簡単に言うと、仮想化タイプのオーバーヘッドが最も少ないということです。これは、多くのローエンドボックスで依然として重要であることを意味します。
別のシナリオを考えてみましょう。Apacheが仮想化環境内で実行されています。各ユーザーを分離したい。 Apacheへのchrootアドオン（mod_chroot、mod_securityなど）を介して仮想化されたファイルシステムを提供することは、エンドユーザー間の最大限のプライバシーを確保するための最良のオプションです。これはまた、インテルの収集を防ぐのに役立ち、さらに別のセキュリティ層を提供します。
簡単に言うと、セキュリティをlayersに実装することが重要です。 Chrootはその1つである可能性があります。すべての人やすべてのシステムがカーネルにアクセスできるという贅沢があるわけではないので、chroot [〜＃〜] still [〜＃〜]は目的を果たします。完全なシステム仮想化が本質的に過剰であるさまざまなアプリケーションがあります。
ご質問への回答として
私は特にCentOSを使用していませんが、操作の前にBindが特権を削除することを知っています。ただし、攻撃ベクトルの履歴と潜在的な脆弱性のため、bindはchrootされていると思います。
また、このアプリケーションを自動的にchrootする方が理にかなっています。誰もが完全なシステム/オペレーティングシステムレベルの仮想化にアクセスできないためです。これは、理論的には、CentOSユーザーベースにセキュリティを提供するのに役立ちます。
オペレーティングシステムプロバイダーは、すべての人が同じシステムを実行していると想定しないでください。このように、それらは全体としてセキュリティの追加レイヤーを提供するのに役立ちます...
非常に多くのアプリケーションがこれを使用する、そして明らかにOSがデフォルトで実行する理由があります。それはISセキュリティとして使用されるためです前述のように、注意深く準備することで、攻撃者がほとんどの場合に克服しなければならないもう1つのハードルであり、ほとんどの場合、chroot刑務所のみにダメージを与えます。
これは、古いバージョンのBindに重大で頻繁なセキュリティの脆弱性があった歴史的な理由によるものです。私はこの件について実際に最新の状態にしたわけではありませんが、昔の時代からずっと改善されていると思っています。
もう1つの理由は、より実用的なものであり、通常はインターネットに直接接続する役割で展開されるため、より多くの攻撃、プロービング、および一般的ないたずらが可能です。
したがって、セキュリティ問題の経験則としてよくあることですが、申し訳ありませんが、特にchrootを実行する作業は比較的少ないため、安全です。