マルチサイトホスティング-サイトを相互に保護するために見逃されている重要な脆弱性？
編集＃2 2015年7月23日：以下の設定で見逃された重要なセキュリティ項目を特定する、またはすべてがカバーされていると信じる理由を与えることができる新しい答えを探しています。
編集＃3 2015年7月29日：私は特に、セキュリティ制限を回避するために悪用される可能性があるものを不注意に許可したり、何かを広く開いたままにしたりするなど、設定ミスの可能性を探しています。
これはマルチサイト/共有ホスティングのセットアップであり、共有Apacheインスタンスを使用したい（つまり、1つのユーザーアカウントで実行する）が、PHP/CGIを各Webサイトのユーザーとして実行して、サイトができないことを確認する別のサイトのファイルにアクセスし、見逃しているものがないことを確認したい（たとえば、シンボリックリンク攻撃の防止について知らなかった場合）。
これが私がこれまでに持っているものです：
- PHPスクリプトがWebサイトのLinuxユーザーアカウントおよびグループとして実行され、投獄されるか（CageFSの使用など）、少なくともLinuxファイルシステムのアクセス許可を使用して適切に制限されていることを確認してください。
- Suexecを使用して、CGIスクリプトをApacheユーザーとして実行できないようにします。
- サーバー側のインクルードサポート（shtmlファイルなど）が必要な場合は、
Options IncludesNOEXECを使用して、予期しないときにCGIが実行されないようにします（それほど心配する必要はありませんが） suexecを使用している場合）。 - ハッカーがApacheをだまして別のウェブサイトのファイルをプレーンテキストとして提供し、DBパスワードなどの悪用可能な情報を開示させないように、シンボリックリンク攻撃保護を設定します。
AllowOverride/AllowOverrideListを構成して、ハッカーが悪用できなかったディレクティブのみを許可します。上記の項目が適切に行われていれば、これはそれほど問題ではないと思います。
MPM ITKは、それほど遅くなく、ルートとして実行されなかった場合に使用しますが、共有Apacheを使用したいのですが、安全に行われることを確認してください。
http://httpd.Apache.org/docs/2.4/misc/security_tips.html を見つけましたが、このトピックについては包括的ではありませんでした。
知っておくと役立つ場合は、CageFSとmod_lsapiでCloudLinuxを使用することを計画しています。
他に必ずやるべきことや知っておくべきことはありますか？
EDIT 2015年7月20日：人々は一般的に価値のあるいくつかの優れた代替ソリューションを提出しましたが、この質問は共有Apacheセットアップのセキュリティに関してのみ対象となっていることに注意してください。具体的には、あるサイトが別のサイトのファイルにアクセスしたり、他のサイトを侵害したりする可能性のある、上記でカバーされていないものはありますか？
ありがとう！
私はあなたがこれまでに持っているアイテムに完全に同意します。
私は数年前にそのようなマルチユーザー設定を実行していて、基本的に同じトレードオフを見つけました：mod_phpは高速で（一部はすべて同じプロセス内で実行されるため）、suexecは低速ですが安全です（すべてのリクエストが新しいフォークをフォークするため）処理する）。ユーザーの分離が必要だったので、suexecを使用しました。
現在考えられる3つ目のオプションがあります。すべてのユーザーに独自のphp-fpmデーモンを提供します。これが実行可能かどうかは、ユーザーの数によって異なります。これは、すべてのユーザーがユーザーアカウントを使用して少なくとも1つのphp-fpmプロセスを取得する必要があるためです（デーモンは、プリフォークのようなメカニズムを使用してリクエストをスケーリングするため、プロセスの数とそれらのメモリ使用量が制限要因になる可能性があります）。自動化された構成生成も必要になりますが、それはいくつかのシェルスクリプトで実行できるはずです。
私は大規模な環境ではその方法を使用していませんが、プロセスレベルでユーザーを分離しながら、PHP Webサイトのパフォーマンスを提供するための優れたソリューションであるIMHOは私です。
あなたがこれまでに持っているすべてはよく考えられているようです。私が問題として見ることができる唯一のことは、ほとんどのエクスプロイトが何らかの方法でルートアクセスを取得しようとするという事実です。したがって、各サイトとそれに対応するプロセスおよびスクリプトが正しくjailされ、すべてに独自のユーザーと権限があり、rootを持つハッカーが気にならなかったとしても、設定したすべてを回避します。
私の提案は、ある種のVMソフトウェア（VMware、VirtualBox、Qemuなど）を使用して、各サイトに独自のOSジェイルを与えることです。これにより、システム管理者は心配する必要がなくなります。侵害された単一のサイトについて。ハッカーがサイトのVM）でphp（またはその他のソフトウェア）を悪用してルートを取得した場合は、VMを一時停止し、後で分析します。 、修正の適用、または破損していない状態へのロールバック。これにより、サイト管理者は特定のソフトウェアまたはセキュリティ設定を特定のサイト環境に適用できます（別のサイトが破損する可能性があります）。
これに対する唯一の制限はハードウェアですが、まともなサーバーと正しいカーネル拡張機能があれば、これは簡単に処理できます。ホストとゲストの両方が非常にまばらであることを認めて、私はLinodeでこのタイプのセットアップを正常に実行しました。私が想定しているコマンドラインに慣れていれば、問題はないはずです。
このタイプのセットアップでは、監視する必要のある攻撃ベクトルの数が減り、ホストマシンのセキュリティに集中して、サイトごとに他のすべてを処理できるようになります。
各サイトを独自のApacheデーモンで実行し、Apacheをchrootすることをお勧めします。 Apachechroot環境は/ bin/shにアクセスできないため、すべてのシステムphp関数が失敗します。これは、phpのmail（）関数も機能しないことも意味しますが、外部のメールプロバイダーを使用してメールアプリケーションからメールを送信している場合、これは問題にはなりません。
すでに提供されている優れた技術的な回答がたくさんあります（こちらもご覧ください： https://security.stackexchange.com/q/77/52572 および LAMPを保護するためのヒント）サーバー ）、しかし私はまだここでセキュリティについての重要なポイント（さらに別の観点から）に言及したいと思います：セキュリティはプロセスです。あなたはすでにこれを検討したと思いますが、それを時々考え直すことが（他の読者にとっても）役に立つことを願っています。
たとえば、あなたの質問では、主に技術的な対策に集中します。「この質問は、共有Apacheセットアップのセキュリティに関してのみ対象です。具体的には、共有を実行するときに実行することが重要であるが、上記のリストにないセキュリティ手順はありますか？ ApacheとPHP。」
ここでのほとんどすべての回答と、私が言及した他の2つの質問についても、純粋に技術的であるようです（最新の状態に保つことをお勧めします）。そして私の見解では、これは一部の読者に誤解を招く印象を与える可能性があります。一度ベストプラクティスに従ってサーバーを構成すれば、いつまでも安全な状態を維持できるということです。だから私が答えで見逃している点を忘れないでください：
まず、忘れないでください。セキュリティはプロセスです。特に、ISOを含む多くの標準で推奨されている「Plan-Do-Check-Act」サイクルについてです。 27001（ http://www.isaca.org/Journal/archives/2011/Volume-4/Pages/Planning-for-and-Implementing-ISO27001.aspx ）。 基本的に、これは、セキュリティ対策を定期的に改訂し、更新してテストする必要があることを意味します。
定期的にシステムを更新してください。これは、ゼロデイ脆弱性を使用した標的型攻撃には役立ちませんが、ほとんどすべての自動化された攻撃には役立ちます。
システムを監視します。私は答えでこの点を本当に逃しています。私の見解では、システムの問題についてできるだけ早く通知を受けることが非常に重要です。
これは統計がそれについて言っていることです：「浸透から発見までの平均時間は173.5日です」（ http://www.triumfant.com/detection.html ）、「検出までの日数の中央値205」 "（ https://www2.fireeye.com/rs/fireye/images/rpt-m-trends-2015.pdf ）。そして、私はこれらの数字が私たち全員が望んでいるものではないことを願っています。
サービスの状態（Nagiosなど）を監視するだけでなく、侵入検知システム（OSSEC、Snort）やSIEMシステム（OSSIM、Splunk）を監視するためのソリューション（無料を含む）はたくさんあります。複雑すぎる場合は、少なくとも「fail2ban」などを有効にするか、ログを別のsyslogサーバーに転送して、重要なイベントに関するEメール通知を送信できます。
繰り返しますが、ここで最も重要な点は、選択する監視システムではありません。最も重要なことは、いくつかの監視を行い、「Plan-Do-Check-Act」サイクルに従って定期的にそれを修正することです。
脆弱性に注意してください。モニタリングと同じです。 Apacheまたは設定に重要なその他のサービスに重大な脆弱性が発見されたときに通知を受けるには、いくつかの脆弱性リストを購読してください。目標は、次の計画された更新の前に現れる最も重要なことについて通知されることです。
インシデントが発生した場合の対処方法を計画します（「計画-実行-チェック-実行」サイクルに従って定期的に更新および改訂します）。安全な構成について質問する場合は、システムのセキュリティが重要になることを意味します。しかし、すべてのセキュリティ対策にもかかわらずシステムがハッキングされた場合はどうすればよいですか？繰り返しになりますが、ここでは「OSの再インストール」のような技術的な対策だけを意味するのではありません。適用法に従ってどこで事故を報告する必要がありますか？サーバーをすぐにシャットダウン/切断することはできますか（会社の費用はいくらですか）？主な責任者が休暇中または病気の場合、誰に連絡すべきですか？
バックアップ、アーカイブ、および/または交換/レプリケーションサーバーを用意します。セキュリティは、サービスの可用性も意味します。バックアップ/アーカイブ/レプリケーションを定期的にチェックし、復元手順も定期的にテストしてください。
侵入テスト？ （繰り返しになりますが、「Plan-Do-Check-Act」サイクルを参照してください:)多すぎると感じた場合は、少なくとも、マルウェアやセキュリティの問題についてWebサービスをスキャンする無料のオンラインツールを試すことができます。
SELinuxはmod_selinux。簡単なハウツーがここに紹介されています：
手順が少し古くなっているので、これがRHEL7.1で機能するかどうかを確認しました。
私は Fedora 19のバージョン を使用し、RHEL 7.1 + EPELに対してモックでコンパイルしました。
基本的なepelconfigモックを使用する場合のYMMVには、次のものが付属しています。
[mockbuild@Fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
mod_selinux-2.4.3-2.fc19.src.rpm
最初にターゲットシステムをアップグレードして、selinux-policyは現在です。
ターゲットボックスにインストール（または最初にローカルミラーに配置）：
yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm
ここで、Apacheの各仮想ホストにカテゴリを割り当てる必要があります。これは、以下の例のように
selinuxDomainValという行を追加することによって行われます。<VirtualHost *:80> DocumentRoot /var/www/vhosts/Host1 ServerName Host1.virtual selinuxDomainVal *:s0:c0 </VirtualHost> <VirtualHost *:80> DocumentRoot /var/www/vhosts/Host2 ServerName Host2.virtual selinuxDomainVal *:s0:c1 </VirtualHost>次に、各ホストのドキュメントルートで、httpd構成でラベル付けされたものと同じカテゴリにドキュメントルートのラベルを付け直します。
chcon -R -l s0:c0 /var/www/vhosts/Host1 chcon -R -l s0:c1 /var/www/vhosts/Host2システムの再ラベル付けを行った場合にラベル付けが尊重されるようにしたい場合は、ローカルポリシーも更新することをお勧めします。
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/Host1(/.*)?' semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/Host2(/.*)?'
ユースケースは、Dockerコンテナに最適です。
各コンテナは、追加のセキュリティとして各Apacheコンテナグループに割り当てられた一意のユーザーIDを使用して、顧客またはクライアントを表すことができます。重要なのは、Apacheスタックを起動する前に、コンテナーの起動時にroot権限を削除することです。各顧客は、独自のパスワードを使用して独自のDBサービスを利用できます。数十台の仮想マシンを立ち上げるという頭痛の種はなく、それぞれが独自の特別なスノーフレークカーネルやその他のオーバーヘッドを必要とします。結局のところ、dockerの中心はchrootです。適切に管理すれば、私はそれをいつでも典型的な仮想クラスターに引き継ぐでしょう。
すでに多くの良い提案がここにあります。ただし、これまでの議論では見逃していたことがある。
Webページの配信の一部として実行されるプロセス以外のプロセスに注意してください。つまり、信頼できないデータにアクセスするすべてのcronジョブが、ユーザーによって定義されているかどうかに関係なく、適切なユーザーとして適切な刑務所で実行されていることを確認してください。
私の経験では、ログ分析のようなものは、ホスティングサービスによって提供される場合、ほとんどの場合ルートとして実行され、ログ分析ソフトウェアには、私たちが望むほど多くのセキュリティ監査が提供されません。これをうまく行うのは少し注意が必要で、セットアップに依存します。一方では、ルート所有の（つまり親プロセスの）Apacheプロセスが、ユーザーが侵害する可能性のあるディレクトリに書き込むことは望ましくありません。それはおそらく刑務所に直接書いていないことを意味します。一方、分析のためにこれらのファイルを刑務所内のプロセスで利用できるようにする必要があり、それを可能な限りリアルタイムに近づける必要があります。 jailに、ログを含むファイルシステムの読み取り専用マウントへのアクセス権を付与できる場合は、それで問題ありません。
PHPアプリは通常、独自の静的ファイルを提供しません。共有Apacheプロセスがある場合、Apacheプロセスはホスト環境から刑務所から直接データを読み取っていると思いますか？もしそうなら、それはさまざまな懸念を開きます。
.htaccessファイルは明らかなものであり、許可する内容に十分注意する必要があります。ほとんどではないにしても、多くのphpアプリは、.htaccessファイルの配置に大きく依存しています。これは、計画したスキームを破壊せずに許可することはおそらく不可能です。
とにかく静的ファイルとは何かをApacheがどのように決定するかはあまり明白ではありません。例えば*.php.gifまたは*.php.enファイルで何をしますか？このメカニズムまたは別のメカニズムが静的ファイルとは何かに関する差別をだましている場合、Apacheが刑務所の外からphpを実行することは可能ですか？静的コンテンツ用に別の軽量Webサーバーをセットアップします。これは、動的コンテンツを実行するためのモジュールで構成されておらず、静的サーバーに送信する要求と動的サーバーに送信する要求を決定するロードバランサーがあります。
StefanのDockerの提案に関しては、コンテナーの外部に配置され、動的コンテンツの各コンテナー内のphpデーモンと通信する単一のWebサーバーを使用すると同時に、Dockerコンテナー内に配置される2番目のWebサーバーを使用することができます。これは、それぞれがコンテンツに使用するボリュームを共有するため、静的コンテンツを提供できます。これは、前の段落とほとんど同じです。さまざまな刑務所タイプのアプローチの中でdockerを賞賛しますが、これまたは他の刑務所タイプのアプローチでは、他にも多くの問題を解決する必要があります。ファイルのアップロードはどのように機能しますか？各コンテナにファイル転送デーモンを配置していますか？ PAASスタイルのGitベースのアプローチを採用していますか？コンテナー内で生成されたログにアクセスできるようにして、ロールオーバーするにはどうすればよいですか？ cronジョブをどのように管理および実行しますか？ユーザーに任意の種類のシェルアクセスを許可しますか。そうであれば、コンテナー内の別のデーモンですか？などなど.
最初に目には見えないのはプロセス管理なので、1つのプロセスがCPUまたはRAM（または、I/Oのことですが、ファイルシステムはそれを防ぐように設計されている可能性があります）の別のプロセスを枯渇させることはできません。 PHPインスタンスへの「コンテナ」アプローチの主な利点の1つは、すべてを1つの「OS」イメージで実行しようとすることと比較して、リソースの使用率をより適切に制限できることです。それはあなたのデザインではありませんが、それは考慮すべきことです。
とにかく、Apacheの背後で実行されているPHPの使用例に戻ると、基本的にプロキシとして機能しています。 suexecは、Apacheユーザーとして何かが実行されるのをしないしません-機能を提供します別のユーザーとして実行します。したがって、1つの懸念は、それがすべて適切に行われていることを確認することです-そのドキュメントページは、その潜在的な危険性を指摘しています： https://httpd.Apache.org/docs/2.2/suexec.html 。だから、あなたが知っている、塩の粒とそのすべて。
セキュリティの観点から、特にそれらが異なるようにコンパイルされている場合、または異なるライブラリ（たとえば、不要な機能が含まれていないライブラリ）に対してコンパイルされている場合は、ユーザーバイナリのセットを制限して（供給をケージに含める）すると役立つ場合がありますbut危険なのは、その時点で、更新の既知のディストリビューションをフォローしておらず、PHPインストール（少なくともユーザースペースツールに関して）。おそらくすでに特定のディストリビューションをcloudlinuxでフォローしているので、それは段階的なリスクですが、それ自体が必ずしも興味深いとは限りません。
AllowOverrideは、意図した場所に置いておきます。多層防御の背後にある中心的な考え方は、スタック全体を保護するために単一のレイヤーに依存しないことです。何かがうまくいかない可能性があると常に想定してください。それが起こったときに緩和します。サイトの前にフェンスが1つしかない場合でも、軽減できるまで繰り返します。
ログ管理が重要になります。分離されたファイルシステムで複数のサービスが実行されている場合、問題を最初から設定していないと、問題が発生したときに相関するアクティビティを統合するのが簡単ではありません。
それは私の脳のダンプです。そこに漠然と役立つ何かがあることを願っています。 :)