コンテンツにスキップ 
PHPハンドラーのセキュリティ FPMとCGIを直接比較した場合、プロセスの分離、ユーザー権限、ハードリミットが最も重要な要素となる。FPMとCGIの直接的な比較では、プロセスの分離とユーザー権限とハードリミットが重要な要素である。専用プールを持つFPMがリスクを低減する一方で、古典的なCGIは厳格な分離を提供するが、高いオーバーヘッドによる待ち時間とCPU負荷が発生する理由を示す。.
中心点
- 断熱 は、攻撃対象領域とクロスアカウントリスクを決定する。.
- FPMプール ユーザーを分け、制限を設定し、リソースを保護する。.
- CGI は強く分離されるが、リクエストごとにCPUと時間がかかる。.
- オペキャッシュ は、アカウントごとに別々のストレージ・セグメントを必要とする。.
- シェアードホスティング 専用のFPMインスタンスから恩恵を受ける。.
PHPハンドラーはどのようにセキュリティを形成するか
各ハンドラーはウェブサーバーとPHPインタプリターを接続しますが 実行 mod_php はPHPを直接ウェブサーバプロセスにロードします。 これは速度を提供しますが、同じユーザコンテキストを共有し、 ホスティングのリスクを増加させます。CGI はリクエストごとに新しいプロセスをターゲットユーザーの下で開始し、 権限をきれいに分離しますが、顕著なオーバーヘッドが発生します。FastCGIはプロセスを生存させ続け、起動コストを削減しますが、 最新のマルチユーザーセットアップが要求する細かい制御を提供するのは FPMだけです。FPMの方が好きなのは、効率を落とすことなく、プールを分け、UIDを分け、 アカウントごとに厳しい制限をかけることができるからです。.
FPMとCGI：日常生活における安全性の区分け
直接比較すると、CGIは厳密に分離するが、FPMは分離を継続する。 パーマネント で、レイテンシーを低く保つ。FPMプールは、それぞれのアカウントのユーザーで実行され、パスを分離し、リソースをカプセル化する。こうすることで、サイトAで悪用された場合、サイトBへのアクセスを防ぐことができる。さらに、memory_limit、max_execution_time、request_terminate_timeoutにより、不具合のあるスクリプトの影響を制限しています。CGIはリクエスト後にすべてのプロセスを終了させるが、常に拡張機能を起動したりロードしたりしてCPU時間を浪費する。そのため、共有環境では FPM が主流となり、理想的にはドメインやプロジェクトごとの専用プールとなります。.
共有ホスティングにおける分離：リスクと対策
共有環境では、最大の ホスティング・リスク, アカウントが意図せずにリソースや権限を共有すること。攻撃者は、脆弱なファイル・パーミッション、欠陥のあるテンポラリ・ディレクトリ、分離されていないキャッシュを狙う。アカウントごとに専用のFPMプールを使って、プロセス、ファイルパス、ログ、OPcacheセグメントをカプセル化しています。また、アップロードパスを分離し、制限付きマウントオプションとクリーンオーナーモデルでシンボリックリンク攻撃を防ぎます。マルチレベル プロセス分離 chroot、CageFS、またはjailsを使用すると、攻撃者がホストシステムに到達できないため、侵入の影響が大幅に減少します。.
リソース管理：プール、制限、タイムアウト
FPMはリソースをターゲットにできるので得点になる 割り当てる を使うことで、悪用を防いでいます。pm.max_childrenを使用して同時のPHPプロセスを制限し、pm.max_requestsはメモリリークを防ぐためにXリクエスト後に長期間のワーカーを再起動します。アップロードについては、post_max_sizeとupload_max_filesizeを設定して、通常のワークフローは実行するが、巨大なファイルは受け付けないようにしている。CPUとRAMのシステム全体にわたるcgroupsと組み合わせることで、ホストはピーク負荷時でも応答性を維持する。.
性能と安全性を数値で比較
ハンドラーを直接比較すると、現実的な違いが明らかになる。 有形. .以下の概要は、意思決定と期待値の調整に使用しています。この値は実際のセットアップにおける典型的な傾向を示しており、共有ホスティングのシナリオにおいて FPM が第一の選択肢である理由を示しています。CGIは再起動による堅牢性を優先し、FPMは分離と速度のバランスをとり、LSAPIはLiteSpeedスタックで輝きます。重要であることに変わりはありません：制限のない分離はほとんど役に立ちませんし、分離のない制限も同様です。.
| ハンドラー | パフォーマンス | セキュリティ | RAM消費量 | 断熱 | こんな方に最適 |
|---|---|---|---|---|---|
| mod_php | 高い | 低い | 低い | 低い | 小規模でシンプルなサイト |
| CGI | 低い | 高い | 高い | 高い | テスト、厳格な分離 |
| FastCGI | ミディアム | ミディアム | ミディアム | ミディアム | 移行期 |
| ピーエッチピーエフピーエム | 非常に高い | 高い | 低い | 高い | 共有ホスティング、CMS |
| suPHP | 低い | 非常に高い | 高い | 非常に高い | 最大限のファイルセキュリティ |
| LSAPI | 非常に高い | ミディアム | 非常に低い | ミディアム | LiteSpeedによる高トラフィック |
この並置から、私は明確な結論を導き出した。 結果マルチユーザーホスティングの場合、FPMはパフォーマンス単位あたりの全体的なセキュリティが最も優れています。CGIは、分離が最大でリクエスト数が少ない特殊なケースでは、依然として選択肢の一つです。 私は、複数の顧客がいる環境ではmod_phpを避けています。LSAPIは、LiteSpeedが使用され、RAMが極端に不足している場合に検討に値する。しかし、ほとんどのシナリオでは、明確な制限を持つ個別の FPM プールの利点が欠点を上回ります。.
設定トラップ：FPMスタックの安全なデフォルト
侵入盗の多くは次のような原因で起こる。 設定ミス, エキゾチックな悪用ではなくね。私には2つのスイッチが必須だ。 cgi.fix_pathinfo=0, で制限をかける。 セキュリティ.limit_extensions 実行可能な末尾（例えば .php,.php8,.phtml).Nginxのセットアップでは スクリプトファイル名 が正しく設定され、任意のパスへのリクエストがすり抜けることがない。また、以下のようなほとんど使われない関数も無効にしている。 エグゼック, シェルエグゼック, プロック_オープン そして ポペン 経由 disable_functions. .これは万能薬ではないが、単純なウェブシェルの影響を大幅に軽減する。. オープン・ベース CLIジョブや画像操作ライブラリ、Composerで副作用を引き起こしやすいからだ。アカウントごとの一貫したパスの分離と、クリーンなオーナー権限の方が良い。.
セッション、アップロード、一時ディレクトリの適切な分離
共通 テンプパス は特権昇格の典型である。各FPMプールについて、私は次のように定義している。 session.save_path そして アップロード_tmp_dir ホームの下にあるアカウント固有のディレクトリに、制限付きの権限で、必要な場所にのみスティッキービットを置く。. ノーエグゼック, ノードブ そして ノスイド をマウントすることで、さらなるレベルの攻撃面を減らすことができる。セッションGCでは session.gc_probability/gc_divisor ファイルが 内 私は、ユーザをまたがるグローバルなセッションバケットを拒否します。Redisをセッションに使う人は、名前空間を厳密に分離し、アカウントごとに別々の認証情報と制限を割り当てます。これにより、欠陥のあるコードが他のプロジェクトのセッションに影響を与えることを防ぎます。.
ソケットの設計、認証、systemdのハードニング
FPM プールはソケット経由で通信する。私は UNIXソケット を持つアカウント固有のディレクトリに置く。 0660 そして適切なグループグローバル 0666-ソケットはタブーだ。あるいは、私はTCPだけをバインド・オンで使っている。 127.0.0.1 または内部インターフェイスとファイアウォール上。サービス・レベル システムディー 確実に： NoNewPrivileges=true, プロテクトシステム＝ストリクト, ProtectHome=true, PrivateTmp=true, CapabilityBoundingSet= (空)、以下の制限 メモリーマックス, CPUクォータ, タスクマックス そして リミットNOFILE. .これにより、たとえウェブアプリの脆弱性が攻撃されたとしても、多くのエスカレーション経路を排除することができる。私はまた、プールを独自のスライスに配置し、騒がしい隣人を消して予算を強制する。.
CLI、cron、キューワーカー：ウェブ上と同じ分離
頻繁な ブラインドスポット: php-cli はFPMを通して実行されません。そのため、関連するアカウントのユーザーとして明示的に cronjobs、インデクサー、キューワーカーを起動し、別の php.ini プロジェクトごとに（または php_value-オーバーライド）、制限、拡張、および オープン・ベース-同等です。キューワーカー（一般的なCMSやフレームワークのものなど）には、ウェブプロセスと同じRAM/CPUバジェットを割り当てます。定期的なジョブについては、フィードインポーターに欠陥があってもホストがブロックされないように、バックオフとレート制限を設定しています。パリティは重要です。ウェブプールで禁止されていることが、突然CLIで許可されるようなことがあってはなりません。.
ロギング、スローログ、バックプレッシャー
視認性は、攻撃や設定ミスをどれだけ早く認識できるかを左右する。各プールについて、私は自分の エラーログ そして有効にする リクエスト_スローログ_タイムアウト ベルベット スローログ, ハングのスタックトレースを取得する。. ログ・リミット は、個々のリクエストがログに殺到するのを防ぎます。と pm.status_path とpingエンドポイントを使って、プロセス、待ち時間、利用率をモニターしている。ウェブ・サーバー・レベルでは 料金制限, また、リクエストボディの制限やタイムアウト（ヘッダーとボディの読み取り）を設定することで、バックエンドが過負荷になるのを防ぐことができる。WAFのルールベースは、些細な攻撃ベクトルも遮断することができる。しかし、FPMがアカウントごとの攻撃対象領域を小さく保ち、制限を確実に有効にすることが極めて重要であることに変わりはない。.
複数のPHPバージョンとエクステンションをきれいに分ける
特に共有ホスティングでは PHPバージョン を並行して使っている。私はFPMのバイナリ、拡張機能、設定をバージョンごとに用意しておき、それらを次のようにバインドしている。 アカウントあたり を追加しました。リクエストが誤って間違ったプールに送られないように、 ソケットは別々のディレクトリに置かれます。OPcacheは、各バージョンと各アカウントで分離されたままです；; 再評価 そして validate_timestamps リリース戦略次第だ。私はJITには注意している：典型的なCMSのワークロードをスピードアップさせることはほとんどなく、複雑さを増大させる。エクステンションのロードは最小限にしています。. pdo_mysql 対未使用ドライバー）、外に残っている。.
脅威モデル：典型的な攻撃ベクトルとハンドラーの影響力
実際には、私はいつも同じパターンを目にする：実行可能な末尾を持つファイルのアップロード、安全でないデシリアライズ、不潔なデシリアライズ。 パス情報-転送、ローカルファイルのインクルード、シンボリックリンクのトリックなどである。FPM はこれを自動的には解決しませんが 範囲を限定する妥協したプールは、自分のネームスペースしか見ない。とは セキュリティ.limit_extensions と正しいウェブサーバー設定を行うことで、画像のアップロードがPHPとして解釈されるのを防いでいます。テンポラリパスとセッションパスを分けることで、クロスアカウントセッションやテンポラリファイルの競合を防いでいます。また、ファイルパーミッションの制限も行っています、, umask そして ノーエグゼック-マウントすると、単純なエクスプロイトの成功率は著しく低下する。.
ファイルの権利、ウマスク、所有権の概念
ファイルシステムは依然として頻繁に使用されている。 脆弱性, パーミッションが正しく設定されていない場合。umaskを使ってデフォルトのパーミッションを調整し、アップロードがグローバルに書き込み可能になってしまわないようにしています。正しいUID/GIDを割り当てたsuPHPやFPMによって、スクリプトの所有者とファイルの所有者が一致するようにしています。これにより、サードパーティのプロセスがファイルを変更したりログを読んだりすることを防ぎます。また、機密性の高いパスをロックし、/tmpマウントにnoexecを設定し、読み取りパスと書き込みパスを一貫して分離することで攻撃対象領域を減らしています。.
OPcacheを安全に使用する
キャッシュは高速化をもたらすが、きれいに分離しないと共有メモリを生み出す 副作用. .FPMプールでは、OPcacheをアカウントごとに分けて、キーとコードが重ならないようにしている。コードの変更が正しく反映されるように、開発モードでは validate_timestamps を有効にし、安定したデプロイを行う本番環境でのみ有効にしています。さらに、file_cacheをチェックするのはアカウントのホーム・ディレクトリ内だけで、グローバルにはチェックしない。共有メモリーを使う場合は 共有メモリのリスク そして視界を厳しく制限する。.
ウェブサーバーの組み合わせApache、Nginx、LiteSpeed
フロントエンドの選択は、レイテンシー、TLSハンドシェイク、リクエスト処理に影響する。 目立つ. .mpm_eventを使ったApacheは、keep-aliveとプロキシバッファが正しければ、FPMとうまく調和する。FPMの前のNginxは静的なアセットで納得し、ロードをずらすことができるが、PHPは動的なパスしか受け取らない。LSAPIを使ったLiteSpeedはオーバーヘッドが非常に少ないが、異なるエコシステムに縛られたままである。FPMプールをきれいに分離し、制限を定義し、ログを監視し、キャッシュレイヤーを意識的に設定する。.
ハードニング：chroot、CageFS、Jails
ハンドラに加えて、オペレーティング・システムの分離も決定します。 効果 侵入のchroot、CageFS、Jailsでは、そのアカウントを独自のファイルシステムの世界に閉じ込める。これは、攻撃者がホストバイナリや機密デバイスパスへのアクセスを失うことを意味する。アカウントごとのFPMと組み合わせることで、CMSシステムのプラグインの弱点にも有効な多層防御が実現する。オプションを比較したい場合は、以下を参照してください。 PHPハンドラの比較 スタックを分類するための貴重なオリエンテーション。.
コンテナ、SELinux/AppArmor、そして現実的な期待
などのコンテナやMACフレームワークがある。 セリナックス 或いは AppArmor FPMを効果的に補完する。コンテナ化は、プロジェクトごとに依存関係を束ね、ルートファイルシステムへのアクセスを制限するのに役立つ。イメージは最小限に抑え、不要な機能を削除し、本当に必要なディレクトリだけをマウントする。SELinux/AppArmorプロファイルは、システムコールを制限し、プロセスがコンテキスト外で動作するのを防ぎます。重要であることに変わりはない：コンテナはFPMの分離とクリーンなファイル・パーミッションの代わりにはならない。コンテナはエラーを遮断する追加レイヤーを形成するものであって、基本を置き換えるものではない。.
ホストとチームのための実践的チェックリスト
プロジェクトでは、私は明確なものから始める。 シーケンスまず技術的にアカウントを分け、それからドメインごとにFPMプールを展開します。それから現実的な制限を設定し、負荷のピークを測定し、pm.max_childrenとpm.max_requestsを調整する。その後、ファイルのパーミッションをチェックし、アップロードディレクトリを保護し、不要な書き込みパーミッションを削除する。プールごとにOPcacheを設定し、コード、セッション、キャッシュが分離されたままになるようにする。最後に、フェイルオーバーをテストする。保護メカニズムが確実に機能するまで、ハング、DoSパターン、メモリ不足の状況をシミュレートする。.
簡単にまとめると
私にとって確かなことは、FPMは最高のものを提供してくれるということだ。 バランス 特にFPMとCGIを比較した場合、セキュリティと性能の面で優れている。CGIは、絶対的な分離が速度よりも優先される場合に有用であることに変わりはないが、 FPMは、オーバーヘッドを大幅に減らしながら、同様のセキュリティ目標を達成する。専用プール、ハードリミット、分離されたキャッシュは、共有環境における ホスティングのリスクを大幅に軽減します。プロセスの分離、クリーンなファイル・パーミッション、制御されたOPcacheの利用によって補完され、ホストは決定的なガードレールを設定します。これらのコンポーネントを一貫して組み合わせることで、レスポンスタイムを抑えながらプロジェクトを効果的に保護します。.
