CloudLinux SecureLinks が停止します シンボリンク-共有サーバー上での攻撃。具体的には、安全でないシンボリックリンクを カーネル-レベルで防止されます。これにより、リンクの所有者とターゲットファイルの所有者が一致する場合にのみ、プロセスがリンクを追跡できるようになるため、機密ファイルを保護しています。.
中心点
- カーネルの保護 他のユーザー間のリンク追跡をブロックします。.
- 所有者審査 シンボリックリンクと対象ファイルを厳密に紐づけます。.
- ハードリンクのブロック 外部ファイルへのリンクを禁止する。.
- 共有ホスティング 孤立したままであり、強靭さを保ち続ける。.
- シンプル sysctl パラメータによる有効化。.
共有ホスティングにおけるシンボリックリンク攻撃がこれほど危険な理由
シンボリックリンク攻撃は、 サービス内容 Apache、PHP-FPM、ファイルマネージャーなどと同様に、シンボリックリンクを介して外部ファイルを開くことで、結果として アカウント 情報を広範囲に漏洩させてしまいます。多数のアカウントが存在する混合環境では、ディレクトリ構造が複雑になりがちであり、権限設定の不備によって重要なデータが容易にさらされてしまうことがよくあります。攻撃者は、他のユーザーの設定ファイル、認証情報、あるいは一時的なデータへのリンクを仕込みます。 保護策が講じられていない場合、プロセスは改ざんされたパスをたどり、本来は閲覧すべきではないコンテンツを読み取ってしまう。厳格なリンク検証はまさにこの脆弱性を解消するものであり、これによりデータ漏洩や意図しないアカウントの乗っ取りのリスクを大幅に低減できる。.
CloudLinux SecureLinksがカーネルレベルでどのように機能するか
SecureLinksは以下を確認します ファイルシステム-レベルで、シンボリックリンクの所有者がターゲットファイルの所有者と一致するかどうかを確認し、一致しない場合はアクセスを拒否するため、重要な パス 確実にブロックします。このアプローチはアプリケーションフィルターよりも深いレベルで機能するため、PHP、WebDAV、あるいはFTPクライアントを介して行われるような不正な手法を阻止しやすくなります。たとえWebアプリケーションに脆弱性があっても、カーネルがリンクの追跡を制御し続けます。 私は、多くのインスタンスが並行して実行されている、負荷の高い共有サーバーにおいて、特にこの利点を活用しています。より詳細な解説については、以下の 詳細な概要, 、その中核となるロジックと保護範囲を記述したものです。.
システム要件と互換性
実際のところ、私にとって最も重要なのは、SecureLinksが一般的な環境とどれだけうまく調和するかという点です。最新のCloudLinuxバージョンでは、このメカニズムは安定して動作し、 エクステンドフォー そして エックスエフエス; ネットワークファイルシステム（NFSなど）が混在する環境では、エクスポートオプションによってリモートファイルシステムの所有者に関する挙動が異なるため、特に徹底的にテストを行っています。 KVMやVMwareのような仮想化レイヤーについては、ゲストシステム内でカーネルレベルでの保護が機能するため、特に問題となることはありません。重要：古いカーネルでは、保護されたリンクのフラグの名称が異なる場合や、完全にはサポートされていない場合があります。 そのため、目標とするパラメータが存在するかどうか、また、関連するすべてのサービス（Webサーバー、PHP-FPM、Cron、スキャナー）がローカルパス上で動作しているか、あるいはマウントオプションによって明確に定義された境界が設定されているかを、早い段階で確認するようにしています。.
他の保護措置との区別および連携
SecureLinksは、次のような仕組みとは競合関係にありません セリナックス 或いは AppArmor, 、むしろそれを補完するものです。MACポリシーがコンテキストに応じてアクセスを制限する一方で、SecureLinksは「外部」のリンクへの追跡を的を絞って防止します。Webサーバーレベルでは、さらに SymLinksIfOwnerMatch そして無効にする FollowSymLinks 適切な場所であればどこでも適用可能です。これらのアプリケーションポリシーはすでに多くの攻撃を阻止していますが、アプリの正しい設定に依存しています。一方、カーネルチェックは、vHost ルールや .htaccess ルールとは独立して機能します。 これらを総合することで、堅牢な防御チェーンが形成されます。CageFSがディレクトリを隔離し、SecureLinksがリンクの悪用を阻止し、Webサーバーが適切なパス解決を強制し、SELinux/AppArmorがプロセスを所定の範囲内に拘束します。.
重要なカーネルパラメータと適切なデフォルト値
実際の運用では、目的に合わせて Sysctl-所有者の確認やリンクの作成を管理するスイッチにより、私は アクセスエラー システム全体でこれを禁止します。特に、fs.enforce_symlinksifowner および fs.symlinkown_gid は、所有者の一致を厳格に適用する上で重要です。 さらに、専用の `protected` オプションを用いて、ハードリンクおよびシンボリックリンクの作成を制限しています。この組み合わせにより、パス処理の初期段階で典型的な攻撃経路を阻止できます。以下の概要では、一般的なパラメータと、実際の運用におけるその効果について示します。.
| パラメータ | 目的 | 代表値 | 効果 |
|---|---|---|---|
| fs.enforce_symlinksifowner | シンボリックリンクを追跡する際にオーナーチェックを強制する | 1 | プロセスは、リンクの所有者とリンク先の所有者が同一である場合にのみ、リンクを追跡できる |
| fs.symlinkown_gid | 厳格な動作を制御するGIDを定義する | 典型例：WebサーバーのGID | 厳格な審査の対象となるグループを限定する |
| fs.protected_symlinks_create | 外部からのシンボリックリンクの作成を防止する | 1 | 非特権ユーザーは、他の所有者が所有するファイルへのシンボリックリンクを作成しません |
| fs.protected_hardlinks_create | 外部ハードリンクの作成を無効にする | 1 | ハードリンクを利用した回避策はブロックされます |
実践：安全な標準パスとセッション
多くの情報漏洩は共有ディレクトリで発生します。そのため、私は session.save_path, アップロード_tmp_dir およびアカウントごとの一時作業ディレクトリ。世界書き込み可能領域については、スティッキービットを「厳格」に設定しています（chmod 1777) そして、可能であれば nosuid,nodev,noexec, 、誤った使用法があった場合でもコードが実行されないようにするためです。リリース用のシンボリックリンクを使用するアプリケーション（例： current → releases/xyz)、リンクとリンク先が同じ所有者に属している限り、引き続き機能します。 一方、グループ単位で複数のユーザーが書き込みを行うチームディレクトリでは問題が生じます。ここでは専用のGIDを設定し、SecureLinksがどのGIDに対して厳密に検証を行うかを明確にする予定です。これにより、セキュリティを損なうことなく、正当なワークフローが所有者チェックによって阻害されるのを防ぎます。.
手順：有効化とテスト
実際には、パラメータを Sysctl-設定を適用し、sysctl -p で読み込み、すぐに ログ-テストアクセス時の挙動。簡単な確認：2人のユーザー、ターゲットアカウント内のテストファイル、攻撃者アカウント内のシンボリックリンク――ファイルの読み取りは失敗するはずだ。並行して、Webサーバーのワーカー、PHP-FPMプール、ファイルマネージャーにおいて、予想される拒否反応がないか確認する。 誤検知が発生した場合は、GIDの割り当てやプロセスの識別情報を確認します。これは、誤ったグループ設定がマッチングを無効にしてしまう可能性があるためです。テスト結果が再現可能になって初めて、その設定を広く展開します。.
展開戦略と代替案
私はSecureLinksを「ビッグバン」方式で一度に有効化することは決してなく、段階的に有効化しています。まずは 監査モード （利用可能な場合はログ分析のみ）またはテスト環境において、その後、選定された本番ノードで綿密な監視を行いながら実施します。異常が発生した場合は、 sysctl -w スイッチの設定をリアルタイムで調整し、必要に応じて迅速にロールバックします。並行して、影響を受けるパスやGIDを記録し、明確な例外処理を設計できるようにしています。構成管理（例：Ansible経由）により、すべての場所で同一のデフォルト設定が適用され、設定のずれを防ぐことができます。 メンテナンスウィンドウでは、ワーカープロセスのグループ変更を確実に反映させるため、短時間のアプリ再起動を計画しています。.
CageFS およびサイト分離との連携
SecureLinksはこれを防止します リンクの悪用, 一方、CageFSはアカウントごとにディレクトリをカプセル化するため、私は複数の レイヤー 安定性を確保する。この組み合わせにより、マルチユーザー環境における横方向の動きが大幅に低減される。まずアイソレーションを設定し、その後にリンク保護を設定することで、両方のレベルが確実に機能するようにしている。ファイルシステムカプセル化の詳細については、以下の簡潔な入門ガイドが参考になる。 CageFSの分離. さらに、ユーザー権限とPHPハンドラーは可能な限り制限するようにしています。.
よくある設定ミスとその回避方法
最もよくある間違いは、誤った グループ-ID、デプロイメントにおける所有関係の不明確さ、および一貫性の欠如 シンボリンク-スクリプト内のターゲット。そのため、有効化する前に、WebサーバーとPHPプールが想定通りのGIDで動作しているかを確認します。ビルドやリリースプロセスでは、ユーザーアカウント間のリンクが生成されないようにする必要があります。 また、バックアップツールやマルウェアスキャナーが正当なアクセスを引き続き実行できることを確認しています。適切なファイル所有者管理を徹底しておけば、後のトラブルシューティング時の手間を省くことができます。.
トラブルシューティング・プレイブックと診断コマンド
何かがうまくいかないときは、再現性のあるチェックに頼っています。 namei -lx /リンクへのパス/ 所有関係を含め、解決に至る一連の経緯をすべて把握しています。. stat リンクとリンク先の所有者およびモードを表示します。以下を通じて ps -o user,group,cmd -p PID プロセスが実際にどのIDで実行されているかを確認します。親プロセスとワーカプロセスの間で不一致があることは、予期せぬ事態が生じるよくある原因です。カーネルメッセージは dmesg あるいはログファイルにも記録されます。Denyエントリには通常、パスとUID/GIDが含まれており、アカウントへのマッピングが容易になります。より詳細なフォレンジックを行う際には、私は 監査役 を有効にし、影響を受けるパスに関連するファイルシステムのシステムコールを記録して、誤検知と実際の攻撃試みを区別する。.
パフォーマンスおよび互換性の観点
追加の チェック 所有者にかかる費用はごくわずかであり、安全性の向上に比べればほとんど ins 負荷が軽減される。利用頻度の高い環境では、安定して低いレイテンシが確認できる。 意図的に共有ディレクトリを利用する特殊なワークロードの検証は依然として重要です。より詳細な分析を行うため、サイトインスタンスをさらに明確に分離するホストコンセプトを採用しています。これに関する情報は、以下の記事にまとめられています。 サイト分離のメリット. 互換性の問題は、たいてい、安全でないリンクを信頼している古いスクリプトによってのみ発生します。.
モニタリング、ロギング、インシデント対応
ロールアウトの後、私はリンクします カーネル-SIEMルールが適用されたログにより、リンクを追跡した際の拒否が即座に確認できるようになり、これにより 攻撃 一目で把握できます。有用な指標としては、アカウントごとのリンクアクセス拒否数、プロセスごとの頻度、および時間枠などが挙げられます。異常値は、エクスプロイトの試みやデプロイの不具合を示唆しています。 対応策としては、プレイブックが有効です。アカウントを一時的にロックし、アーティファクトをバックアップし、パスを分析し、権限を修正します。最後に、原因を文書化し、同様のパターンが再発しないよう設定を調整します。.
cPanel、Plesk、および一般的なスタックへの統合
ホスティングの日常業務では、Webサーバー、PHP、および補助サービスは、多くの場合、独自のサービスユーザーで実行されています（アパッシュ, nginx, lshttpd) およびグループベースのプールID。私は fs.symlinkown_gid その制限は厳しく、ウェブサーバーのユーザーや顧客のFPMワーカーもこの厳格なチェックの対象となります。アカウントごとのPHP-FPMやLSAPIの場合、ワーカーはもともと各顧客アカウントの下で実行されるため、競合が生じることはほとんどありません。 より問題となるのは、一元的に書き込みを行うグローバルスキャナー、バックアップ、キャッシュ（Composer、NPM）などです。ここでは、例外を意図的に設定するか、アーティファクトをアカウントごとのディレクトリに移動するようにしています。 cPanelやPleskなどのコントロールパネルでは、PHPハンドラの選択（suEXEC、FPM、LSAPI）も追加で確認し、「グローバル」なハンドラが意図せず他者のファイルを読み取れないようにしています。.
実務上のよくある質問
多くの管理者から、SecureLinksについて すべて シンボリックリンクがブロックされている――それは間違いです。なぜなら、 アカウント 引き続き機能します。重要なのは、リンクの所有者とファイルの所有者が一致していることです。また、よく聞かれる質問として、「アプリレベルだけで十分か？」というものがあります。私の答えは明確に「いいえ」です。なぜなら、カーネルレベルの検証があれば、Webやスクリプトのロジックを介した迂回を防止できるからです。 隔離、最小限の権限、そしてSecureLinksの組み合わせにより、攻撃者に対するハードルは著しく高まります。.
チームおよびデプロイメントに関する特例とベストプラクティス
リポジトリやビルドシステムを共有するチームでは、リリースが同じアカウントの範囲内で行われるよう注意を払っています。Capistrano のようなシンボリックリンクのレイアウトは、単一のユーザーが所有し続ける限り、問題にはなりません。 アカウントをまたぐリンクは厳格に禁止し、明確に定義されたインターフェース（API、HTTP、メッセージキュー）に置き換えます。グループ作業ディレクトリには、専用のプロジェクトGIDを使用し、明確な umask-の値を設定し、これらのGIDに対して厳格なSecureLinksチェックを適用するかどうかを確認します。これにより、コラボレーションとセキュリティのバランスを保つことができます。 NFS 経由のストレージについては、所有者の一貫性を確保するエクスポートオプションを選択し（本番環境のパスには匿名マップを使用しない）、リンクチェックが期待どおりに機能するかどうかをテストします。 コンテナワークロードについては、テナント間で意図しない近道が生じないよう、マウントパスを明確に文書化します。.
評価とまとめ
CloudLinux SecureLinksは私に クリア シンボリックリンクやハードリンクの悪用に対する保護。これは、パスへのアクセスに関する最終的な判断をカーネルが行うためであり、それによって 攻撃方法 確実に遮断されます。多数のアカウントが存在する共有ホスティング環境では、この制御が即座に効果を発揮します。綿密に設計されたデフォルト設定、明確な所有者管理戦略、そしてテストが、日々の運用を確実に支えます。 CageFS、厳格なPHPハンドラー、ログ監視と組み合わせることで、多層的な防御体制が構築され、システム障害やデータ漏洩の発生確率が大幅に低減されます。ホスティングの責任者は、SecureLinksを基本セキュリティの不可欠な要素として位置づけることが理想的であり、それによって信頼性、可用性、そして評判を持続的に高めることができます。.
