マルチサイトホスティング-サイトを互いに保護するために見逃されている重要な脆弱性？

編集＃2 2015年7月23日：以下の設定で見逃した、またはすべてがカバーされていると信じる理由を与えることができる重要なセキュリティ項目を識別する新しい答えを探しています。

編集＃3 2015年7月29日：私は特に、セキュリティ制限を回避するために悪用される可能性のあるものを不注意に許可したり、何かを広く開いたままにしたりするなど、設定ミスの可能性を探しています。

これはマルチサイト/共有ホスティングセットアップであり、共有Apacheインスタンス（つまり、1つのユーザーアカウントで実行）を使用したいが、各WebサイトのユーザーとしてPHP / CGIを実行して、サイトが別のサイトのファイルにアクセスできないようにします。見落としがないことを確認してください（たとえば、symlink攻撃防止について知らなかった場合）。

ここに私がこれまで持っているものがあります：

• PHPスクリプトがWebサイトのLinuxユーザーアカウントおよびグループとして実行され、投獄されている（CageFSを使用するなど）か、少なくともLinuxファイルシステムのアクセス許可を使用して適切に制限されていることを確認します。
• suexecを使用して、CGIスクリプトがApacheユーザーとして実行できないようにします。
• サーバーサイドインクルードサポート（shtmlファイルなど）がOptions IncludesNOEXEC必要な場合は、予期しないときにCGIが実行されないようにするために使用します（ただし、suexecを使用する場合はそれほど心配する必要はありません）。
• ハッカーがApacheをだまして別のWebサイトのファイルをプレーンテキストとして提供したり、DBパスワードのような悪用可能な情報を開示したりできないように、symlink攻撃から保護します。
• ハッカーが利用できなかったディレクティブのみを許可するように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セットアップのセキュリティに関してのみ対象となっていることに注意してください。具体的には、1つのサイトが別のサイトのファイルにアクセスしたり、他のサイトを侵害したりする可能性がある、上記でカバーされていないものはありますか？

ありがとう！

これまでのアイテムに完全に同意します。

私は数年前にそのようなマルチユーザーセットアップを実行していましたが、基本的に同じトレードオフを見つけました：mod_phpは高速で（一部はすべて同じプロセス内で実行されるため）、suexecは低速ですが安全です（すべてのリクエストが新しいフォークをフォークするため）処理する）。ユーザー分離が必要なため、suexecを使用しました。

現在考えられる3番目のオプションがあります。すべてのユーザーに独自のphp-fpmデーモンを提供します。これが可能かどうかは、ユーザーの数に依存します。これは、すべてのユーザーが、ユーザーアカウントを使用して少なくとも1つのphp-fpmプロセスを取得する必要があるためです（デーモンは、プリフォークのようなメカニズムを使用してリクエストをスケーリングするため、プロセスの数とそれらのメモリ使用量が制限要因となる場合があります）。また、いくつかの自動化された構成生成も必要になりますが、これはいくつかのシェルスクリプトで実行できるはずです。

私は大規模な環境ではその方法を使用していませんが、プロセスレベルでユーザーを分離しながら、PHP Webサイトのパフォーマンスを向上させるための優れたソリューションであるIMHOは使用します。

これまでのところすべてがよく考えられているようです。私が問題として見ることができる唯一のことは、ほとんどのエクスプロイトが何らかの方法でルートアクセスを取得しようとするという事実です。したがって、各サイトとそれに対応するプロセスとスクリプトが正しく投獄され、すべてに独自のユーザーと権限があり、rootを持つハッカーが気にならなかったとしても、設定したすべてを回避します。

私の提案は、ある種のVMソフトウェア（VMware、VirtualBox、Qemuなど）を使用して、各サイトに独自のOS刑務所を提供することです。これにより、システム管理者は単一の侵害されたサイトについて心配する必要がなくなります。サイトのVMでphp（またはその他のソフトウェア）を悪用してハッカーがルートを取得した場合、VMを一時停止して後で分析するか、修正を適用するか、壊れていない状態にロールバックします。これにより、サイト管理者は特定のソフトウェアまたはセキュリティ設定を特定のサイト環境（別のサイトを壊す可能性があります）に適用できます。

これに対する唯一の制限はハードウェアですが、適切なサーバーと適切なカーネル拡張機能があれば、これは簡単に処理できます。私はLinodeでこのタイプのセットアップを正常に実行し、ホストとゲストの両方が非常にまばらであることを認めました。私が想定しているコマンドラインに慣れていれば、問題はないはずです。

このタイプの設定により、監視する必要がある攻撃ベクトルの数が減り、ホストマシンのセキュリティに集中して、サイトごとに他のすべてのものに対処することができます。

各サイトを独自のApacheデーモンの下で実行し、Apacheをchrootすることをお勧めします。Apache chroot環境は/ bin / shにアクセスできないため、すべてのシステムphp関数は失敗します。これは、phpのmail（）関数も機能しないことを意味しますが、外部のメールプロバイダーを使用してメールアプリケーションからメールを送信している場合、これは問題にはなりません。

SELinuxはに役立つかもしれませんmod_selinux。簡単なハウツーがここに紹介されています：

SELinuxを使用してPHPスクリプトを制限するにはどうすればよいですか？

手順が少し古いので、これがRHEL 7.1で機能するかどうかを確認しました。

私はFedora 19のバージョンを使用し、RHEL 7.1 + EPELに対してモックを使用してコンパイルしました。

YMMVは、基本的なepel構成モックを使用する場合、次のものが付属しています。

[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(/.*)?'

すでに多くの優れた技術的回答が提供されています（こちらもご覧ください：https : //security.stackexchange.com/q/77/52572およびTips for Securing a LAMP Server）でも、ここで触れておきますセキュリティに関する重要なポイント（さらに別の観点から）：セキュリティはプロセスです。あなたはすでにこれを検討したと思いますが、それを時々考え直すことが（他の読者にとっても）役に立つことを願っています。

たとえば、質問では主に技術的な対策に集中します：「この質問は共有Apacheセットアップのセキュリティのみを対象としています。具体的には、共有を実行するときに、実行する必要があるが上記のリストにないセキュリティ手順がありますか？ ApacheとPHP。」

ここでのほとんどすべての回答と、私が言及した他の2つの質問についても、純粋に技術的なものであるようです（最新の状態に保つことをお勧めします）。そして、私の見解では、これは一部の読者に誤解を招く印象を与える可能性があります。一度ベストプラクティスに従ってサーバーを構成すれば、いつまでも安全な状態を保つことができます。だから私が答えで見逃しているポイントを忘れないでください：

1. まず第一に、セキュリティはプロセスであり、特に「Plan-Do-Check-Act」サイクルに関するものであることを忘れないでください。これは、 ISO 27001（http://www.isaca.org/ Journal / archives / 2011 / Volume-4 / Pages / Planning-for-and-Implementing-ISO27001.aspx）。基本的に、これは、セキュリティ対策を定期的に改訂し、更新してテストする必要があることを意味します。

2. システムを定期的に更新します。これはゼロデイ脆弱性を使用した標的型攻撃には役立ちませんが、ほとんどすべての自動化された攻撃には役立ちます。

3. システムを監視します。私は答えでこのポイントを本当に逃しています。私の観点からは、システムの問題についてできるだけ早く通知を受けることが非常に重要です。

   統計によると、「潜入から発見までの平均時間は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サーバーに転送して、重要なイベントに関する電子メール通知を受け取ることができます。

   繰り返しますが、ここで最も重要な点は、選択する監視システムではありません。最も重要なのは、監視を行い、「計画、実行、確認、実行」サイクルに従って定期的にそれを修正することです。

4. 脆弱性に注意してください。監視と同じです。設定に重要なApacheまたはその他のサービスに重大な脆弱性が発見されたときに通知を受けるには、いくつかの脆弱性リストに登録してください。目標は、次の計画された更新の前に現れる最も重要なことについて通知されることです。

5. インシデントが発生した場合の対処方法を計画します（そして、「Plan-Do-Check-Act」サイクルに従って定期的に更新および修正します）。安全な構成について質問すると、システムのセキュリティが重要になるということです。ただし、すべてのセキュリティ対策にもかかわらず、システムがハッキングされた場合はどうすればよいですか？繰り返しますが、ここでは「OSの再インストール」のような技術的な対策だけを意味しているわけではありません。適用法に従って事故をどこに報告すればよいですか。サーバーをすぐにシャットダウン/切断することは許可されていますか（会社にとってどれくらいの費用がかかりますか）？主な責任者が休暇中/病気の場合、誰に連絡すべきですか？

6. バックアップ、アーカイブ、および/または交換/複製サーバーを用意します。セキュリティは、サービスの可用性も意味します。バックアップ/アーカイブ/レプリケーションを定期的に確認し、復元手順を定期的にテストしてください。

7. 侵入テスト？（繰り返しますが、「Plan-Do-Check-Act」サイクルを参照してください。）やり過ぎと思われる場合は、少なくともいくつかの無料のオンラインツールを試して、マルウェアとセキュリティの問題についてWebサービスをスキャンすることができます。

このユースケースは、Dockerコンテナーに最適です。

各コンテナは顧客またはクライアントを表すことができ、追加のセキュリティとして各Apacheコンテナグループに一意のユーザーIDが割り当てられます。重要なのは、Apacheスタックを開始する前に、コンテナーの起動時にroot権限を削除することです。各顧客は、独自のパスワードを使用して独自のDBサービスを取得します。数十の仮想マシンを立ち上げる煩わしさはなく、それぞれが独自のスノーフレークカーネルやその他のオーバーヘッドを必要とします。結局のところ、Dockerの中心はchrootです。適切に管理されれば、私はそれを通常の仮想クラスターにいつでも引き継ぐでしょう。

すでに多くの良い提案がここにあります。ただし、これまでの議論では見逃していたことがある。

Webページの提供の一部として実行されるプロセス以外のプロセスに注意してください。つまり、信頼できないデータを扱うすべてのcronジョブが適切なユーザーとして、適切な刑務所で実行されていることを確認します。これらのジョブがユーザーによって定義されているかどうかは関係ありません。

私の経験では、ログ分析のようなものは、ホスティングサービスによって提供される場合、ほとんどの場合rootとして実行され、ログ分析ソフトウェアは私たちが望むほど多くのセキュリティ監査を与えられていません。これをうまく行うには少し注意が必要で、セットアップに依存します。一方では、ルートが所有する（つまり、親プロセス）apacheプロセスが、ユーザーが危険にさらす可能性のあるディレクトリに書き込むことを望まないでしょう。それはおそらく刑務所に直接書いていないことを意味します。一方、これらのファイルを刑務所のプロセスで分析できるようにする必要があり、それをできるだけリアルタイムに近づけたいと考えています。jailに、ログを含むファイルシステムの読み取り専用マウントへのアクセス権を与えることができれば、それは良いことです。

PHPアプリは通常、独自の静的ファイルを提供しません。共有のApacheプロセスがある場合、Apacheプロセスはホスト環境から刑務所から直接データを読み込んでいると思いますか？もしそうなら、それは様々な懸念を開きます。

.htaccessファイルは明白なものであり、許可するものに細心の注意を払う必要があります。ほとんどではないにしても、多くのphpアプリは.htaccessファイルの配置に非常に依存しているため、計画したスキームを覆すことなく許可することはできません。

あまり明白でないのは、とにかくapacheが静的ファイルを決定する方法です。例：*.php.gifor *.php.enファイルで何をしますか？このメカニズムまたは別の方法で静的ファイルとの区別をだましている場合、Apacheが刑務所の外からPHPを実行することは可能ですか？動的コンテンツを実行するためのモジュールが構成されていない静的コンテンツ用に別の軽量Webサーバーをセットアップし、静的サーバーに送信するリクエストと動的サーバーに送信するリクエストを決定するロードバランサーを用意しました。

StefanのDockerの提案に関しては、コンテナーの外側に配置され、動的コンテンツ用に各コンテナー内のphpデーモンと通信する単一のWebサーバーを使用できる一方で、Dockerコンテナーに配置された2番目のWebサーバーも使用できます。これは、それぞれがコンテンツに使用するボリュームを共有し、静的コンテンツを提供できます。これは、前の段落とほとんど同じです。さまざまな刑務所タイプのアプローチの中でdockerを称賛しますが、これまたは他の刑務所タイプのアプローチでは、他にも多くの問題を解決する必要があります。ファイルのアップロードはどのように機能しますか？各コンテナーにファイル転送デーモンを配置しますか？PAASスタイルのGitベースのアプローチを採用していますか？コンテナー内で生成されたログにアクセスできるようにする方法 そして、それらをロールオーバー？cronジョブをどのように管理および実行しますか？ユーザーに任意の種類のシェルアクセスを許可しますか。そうであれば、コンテナー内の別のデーモンですか？などなど

私が最初に目にしないのはプロセス管理なので、あるプロセスがCPUまたはRAMの別のプロセス（または、I / Oのことですが、ファイルシステムはそれを防ぐように設計されているかもしれません）を使い果たすことはできません。PHPインスタンスへの「コンテナー」アプローチの1つの大きな利点は、1つの「OS」イメージ上ですべてを実行しようとするのではなく、リソースの使用をより適切に制限できることです。それはあなたのデザインではないことは知っていますが、それは考慮すべきことです。

とにかく、Apacheの背後で実行されているPHPの使用例に戻ると、基本的にプロキシとして機能しています。suexecは、apacheユーザーとしての実行を妨げません - 別のユーザーとして実行する機能を提供します。したがって、1つの懸念は、それがすべて正しく行われていることを確認することです。そのためのドキュメントページは、その潜在的な危険性を示しています：https : //httpd.apache.org/docs/2.2/suexec.html。つまり、ご存知のとおり、塩の粒などです。

セキュリティの観点から、それは彼らが異なったり別のライブラリに対してコンパイルされている場合は特に、（物資をcagefs）との仕事に、ユーザバイナリの制限されたセットを持つことが役に立つことができます（たとえば、望ましくない機能が含まれていないもの）が、危険なのは、その時点で既知のアップデートのディストリビューションをフォローしておらず、PHPインストールの（少なくともユーザースペースツールに関して）別のディストリビューション（cagefs）をフォローしていることです。おそらくすでに特定のディストリビューションをcloudlinuxでフォローしているので、それは段階的なリスクですが、それ自体が必ずしも興味深いとは限りません。

AllowOverrideは、意図した場所に置いておきます。多層防御の背後にある中心的なアイデアは、スタック全体を保護するために単一のレイヤーに依存しないことです。何かがうまくいかない可能性があると常に想定してください。それが発生したときに緩和します。サイトの前にフェンスが1つしかない場合でも、できる限り軽減するまで繰り返します。

ログ管理が重要になります。分離されたファイルシステムで複数のサービスを実行している場合、問題を最初から設定していなければ、問題が発生したときに相関するアクティビティを統合するのは簡単ではありません。

それは私の脳のダンプです。そこに漠然と有用な何かがあることを願っています。:)