Dockerを使用してオンラインサーバーのセキュリティを強化できますか？
私はオンラインのWebサーバーを荒らされました、彼らは私のホストされたWordPressサイトから侵入し、そこから特権がエスカレートされました。
WordPressをDockerに配置すると、WordPressエクスプロイトのリスクを軽減するための適切な方法になりますか？
P2kが言ったように、dockerはWordpressの問題を解決しません。しかし、特権昇格のリスクを軽減することを意味する場合答えは「はい」になるはずです。
コンテナー（LXC、openVZ、Solarisゾーンなど）の主な機能の1つは、まさに権限の分離です。 Dockerは、さまざまなコンテナー（およびqemu、またはchroot！）に対する単なる汎用フレームワークです。このようにして、Dockerベースのシステムは、選択した基盤よりも安全になることはありません。 LXC（Dockerの有無にかかわらず）を使用している場合は、LXC実装のセキュリティレベルを取得します（これは多少不完全ですが、安全のためにapparmorまたはSElinuxを使用する必要があります）。
コンテナテクノロジーを使用すると、攻撃者をゲートで止めるしかし、あなたのゲート（ワードプレス）は無駄になります。ただし、侵害されたマシン全体よりも、ずっとウェブサイト（コンテナ）を復元する方が簡単です。
それにもかかわらず、適切に設計されたapparmor設定の下でウェブサーバーとデータベースサーバーを実行し、基本的なセキュリティルールを維持する場合（必要でない限り、どこにも書き込みアクセスはなく、頻繁にパッチを適用し、mod_securityなどのWAFを使用します）、とにかくまともなセキュリティレベルに到達できますコンテナ使用のオーバーヘッド。
IMO：コンテナーシステムの使用とコンテナーシステムとしてのDockerの使用：ここでIMOに対処するためのポイントが本当にあるので、私は2つの部分でこの質問に答えます。
コンテナシステムの使用
他の回答で述べたように、コンテナシステムだけを使用しても、セキュリティは向上しません。ただし、コンテナーシステムを使用すると、他の侵害を検出するのに簡単かつ効果的であることが証明されるアクションを実行でき、迅速かつ早期に行動できるようになります。
tripwireまたは類似のものをインストールする： Tripwire （または [〜＃〜] ossec [〜＃〜] のようなツールもログファイルをスキャンして不審なアクティビティがないか確認します。）ファイルシステムに含まれるさまざまなファイルのハッシュを含むデータベースを作成します。これは、予期しないファイルの変更を検出できるようにするための設計です。たとえば、攻撃者がシステムに侵入してWordpressファイルの置き換えを開始した場合などです。これらのツールの弱点は、攻撃者が適切な権限を取得できた場合、データベースを変更してその変更を隠すことができることです。
コンテナーの主な利点は、ゲストファイルシステムが直接であり（VMで頻繁に必要とされる一部のソフトウェアを介してではなく）、ホストファイルシステムにアクセスできることです。ゲストはアクセスできません。これは、ホストでTripwireのようなツールを実行してゲストのファイル変更を監視するという夢の状況です。独自のデータベースが安全である間、異常な変更を直接検出できます（Wordpressサーバーの場合、ゲストシステムの権限をエスカレートし、コンテナをエスケープし、ホストシステムの権限を再度エスカレートして、ついにTripwireデータベースにアクセスできるようにします。
ログを外部化：サーバーは、いわゆるログファイルにすべてのアクティビティを記録します。小規模なシステムでは、これらのログファイルは同じホスト上にあり、主に
/var/logディレクトリにあります。これらのファイルは、システムの妥協を隠すための攻撃者の直接的な標的です（ [〜＃〜] ossec [〜＃〜] これらのファイルを定期的に解析し、警告メールを送信して次の場合に警告することができますログに記録されている不審なアクティビティ）。企業環境は専用の別のマシンに投資してすべての環境からログを収集できますが、コンテナーは、ゲスト環境の外部にログを保存するための
syslogをセットアップする安価で安全な方法を提供し、攻撃者によるアクセスをはるかに少なくします。
これらは単なる例です。実際のところ、コンテナーは、システムのセキュリティを処理する方法に大きな柔軟性を提供します。
コンテナーシステムとしてのDockerの使用
最初の注意として、ますます多くの人々がDockerをセキュリティ指向のコンテナと見なさなくなっています。以下を参照してください：
- ダニエルウォルシュからの講演RHEL Dockerイネーブルメントチームを率いて、「に助言するだけで、コンテナー内で実行されている特権プロセスを想定するコンテナ外で実行される特権プロセスと同じです。 "、
- Dockerに依存していた CoreOS や Kagome のようなプロジェクトは、
- Sandstorm （またはCoreOSのロケット、上記のリンクを参照してください。ただし現在は非常に初期の段階にあるようです）など、Dockerのセキュリティ志向の代替としてセットアップされている新しいプロジェクト。
Docker自体はLXCに基づいています（いくつかの制限があります。以下を参照）。基本的に、LXCではなくDockerを使用するか、本格的なスタンドアロンLXCを使用するか（または、LXCに依存している可能性がある代替ソリューションに移動します）.
選択するソリューションに関係なく、機能とセキュリティの間には常にトレードオフがあります。機能が多ければ多いほど、セキュリティは低くなります。
したがって、Dockerが提供するneed機能が必要な場合は、それで問題ありません。ただし、本当にそれらが必要ない場合は、軽量の代替品について2度考えてみてください。まったく同じジレンマが、Qemu/KVMスタンドアロンを使用するか、Libvirtをインストールするかを選択する必要があるハードウェア仮想化でも発生することに注意してください。
補足ソフトウェアスタックを追加する限り：
- 補足的な依存関係と機能では、軽量版よりも高い特権でコマンドを実行する必要がある場合があります（LXCとQemuの両方は、制限された特権を使用してエンドユーザーアカウントで実行するように設計されていますが、DockerとLibvirtはホストシステムのルートとして動作する必要がありますユーザー）。このような高い権限でコードを実行すると、セキュリティ上の欠陥が見つかった場合に状況が悪化する可能性があります。
- より基本的なインストールを使用した場合には発生しなかった制限と非互換性に直面する必要があります。たとえば、本物のセキュリティを提供するために、LXCの最終バージョン1.0は 非特権コンテナー を1年半前に提供しました。ただし、Dockerはまだ解決していません 複数のライブラリの非互換性の問題 。この機能はまだ利用できず、古くて安全性の低いLXC機能に依存しています。
- ソフトウェアとライブラリの山に依存している場合、どこかで問題が発生するとプロジェクトがブロックされる可能性があります。依存するソフトウェアとライブラリが少ないほど、ブロッキングの問題が発生する可能性が低くなり、解決が容易になります（ログと分析の可能性が少なくなるだけでなく、前述の非互換性により、一部の基本的なレイヤーで回避策が機能しなくなる可能性があります。別の場所）、
- 最後に、技術的な問題によりプロジェクトがブロックされる可能性がありますが、セキュリティの脆弱性を引き起こす可能性もあります。使用するソフトウェアが少ないほど、攻撃対象領域が小さくなります。つまり、リモートの攻撃者が環境を危険にさらすことができる脆弱性の正しい組み合わせが存在する可能性が小さくなります。
したがって、これによってDockerの使用や、他の種類の野心的な複雑なプロジェクトの構築が妨げられることはありません。ただし、信頼するソフトウェアによってもたらされる機能を評価する必要があります。
ベルとホイッスルでいっぱいの迷宮システムを使用している人をあまりにも頻繁に目にしますが、実際にはほんの少ししか知りません。それは妥協の扉です。
Wordpressをドッカーに入れると、Wordpressエクスプロイトのリスクを軽減するための適切な方法になりますか？
いいえ-脆弱なトップレイヤーがまだあるのに、ベースレイヤーの変更で何かが改善されるのはなぜですか？
データやサービスの分割などにいくつかの概念を適用できます。しかし、それは別の話です。また、サービス（WordPressはこちら）に変更はありません。
繰り返しになりますが、セキュリティ侵害はWordPressにありました。したがって、唯一の解決策は、アプリケーションを交換するか、それを強化することです。 （定期/高速更新。（不要な）プラグインを削除してください。など）