Apache mod_status のセキュリティ対策を講じ、ステータス値を正しく評価する

mod_status が表示するもの

Apacheモジュール「mod_status」は、稼働中のWebサーバーに関する情報を提供します。これにより、現在何人のワーカーが稼働中か、どのリクエストが処理されているかといった情報を確認できます。 以下の説明は Apache HTTP Server 2.4 に関するものです。開発ブランチのドキュメントはこれとは別のものであり、検証なしにこのバージョンに適用することはできません。

A ハンドラー 設定されたURLパスに対するステータス出力を生成します。Locationセクションでは、このパスをハンドラに server-status を割り当てる。このために、DocumentRoot内に同名のファイルが存在する必要はない。したがって、このパスはサーバーの診断へのアクセス経路であり、ファイルシステムから提供される通常のページではない。

手動での診断には、HTML表示が適しています。以下の形式の ?auto 監視システムが定期的に取得できる、機械可読形式のデータを提供します。利用可能な詳細情報は、サーバーの設定などによって異なります。このパラメータは、エンドポイントを独立したサービスとして扱いません。そのため、その出力も不正アクセスから保護する必要があります。

前提条件として、mod_status が読み込まれており、適切な Apache 設定ファイルを編集する権限がある必要があります。 また、アクセス制限を行うには、必要な認証モジュールが利用可能である必要があります。モジュールの有効化方法や、それに関連するファイルはディストリビューションやインストール環境によって異なるため、特定のファイルパスを一般的な出発点として挙げることはできません。

のために Apacheの監視 この出力は診断の参考にはなりますが、完全なアプリケーション・パフォーマンス監視とは言えません。例えば、ワーカーが稼働中であることを示してはいますが、処理の遅延の原因がデータベース、バックエンド、あるいは動作の遅いクライアントのいずれにあるのかについては、それ自体では説明できません。こうした原因を特定するには、適切なアプリケーションデータ、システムデータ、およびログデータが別途必要となります。

ステータスデータとそのセキュリティへの影響

ステータスページには、稼働中のワーカーや空きワーカーのほか、起動または再起動時刻、実行時間などの情報が表示されます。稼働中のワーカーは、照会時点では空きリソースとして利用できません。稼働中と空きワーカーの比率がどれほど深刻な状況にあるかは、その推移や実際に設定されているワーカーの上限値を踏まえて初めて判断できます。

実行時間は、集計値を時間軸上で位置づけるのに役立ちます。開始時点からの平均値は、一時的な負荷のピークを隠してしまう可能性があります。同様に、空きワーカーが少ない状態でのクエリ実行結果は、あくまでその時点の断片的な状況に過ぎません。応答時間やエラー情報と併せて繰り返しクエリを実行することで、リソース不足の可能性を調査するためのより確かな根拠が得られます。

と一緒に 拡張ステータス Apacheは、集計されたアクセス数やデータ量、現在のホストやリクエストに関する情報など、追加の詳細情報を記録します。mod_statusを読み込む際、Apache 2.4ではこの記録機能がデフォルトで有効になっています。とはいえ、設定を明示的に決定することで、各運用環境においてどの程度の詳細度を想定しているかを明確にすることができます。

より詳細な記録には代償が伴います。追加の負荷が発生し、サーバーの動作が遅くなる可能性があります。したがって、詳細情報を自動的に「無料の機能向上」と見なすのではなく、診断上のメリットとこの負荷を慎重に比較検討してください。一方で、ExtendedStatus がない場合、進行中のリクエストの特定に役立つ情報が欠落してしまいます。

この出力には、実行中のリクエストやクライアント情報が含まれる可能性があります。したがって、これを 機密性の高い業務データ 公的な健康診断としてではなく。HTMLビューと ?auto 同じアクセス保護が必要です。推測されにくいパスであっても、それを知っている人や発見した人によるアクセスを防ぐことはできません。

アクセス経路とワーカーモデルを確認する

変更を行う前に、インストールされているApacheのバージョンと、有効になっているマルチプロセッシングモジュール（略称MPM）を確認してください。また、対象のリスナーを処理している仮想ホスト、リバースプロキシがリクエストを転送しているかどうか、およびすでに適用されているアクセスルールについても確認してください。 こうした全体像を把握して初めて、新しいルールがどこに作用し、どの既存の設定に影響を与える可能性があるかを判断できます。

ローカルのモニタリングエージェントは、ループバックアドレスを介してステータスを取得できる。しかし、ローカルでの取得に成功したとしても、それは単に、選択されたアドレス、ポート、および仮想ホストを用いたその特定の経路が機能していることを示すに過ぎない。他のホストが保護されていること、あるいは外部からのアクセスが失敗することを証明するものではない。

2つ目の方法は、リバースプロキシと別の仮想ホストを経由する方法です。そこでは、別のリダイレクトやアクセスルールが適用される可能性があります。また、Apacheが認証のために実際にどのクライアントアドレスを参照しているかを確認する必要があります。以下の アクセス経路 そのため、プロキシ、ホストの選択、Apacheのルールを含め、ローカルでのテスト結果をトポロジー全体に適用するのではなく、

MPMは、Apacheが処理のためにプロセスや、場合によってはスレッドをどのように使用するかを決定します。プロセスとはオペレーティングシステムの単位であり、スレッドはプロセス内で実行され、そこでタスクを処理することができます。したがって、ワーカー数の重要性は、使用されるモデルによって異なります。 Apacheのワーカーモデルの比較 Prefork、Worker、Event の違いについて解説します。

とりわけ event-MPM 開いている接続が、必ずしも常に占有されているワーカースレッドと同義であるとは限りません。特定の待機状態は、リクエストのアクティブな処理とは異なる扱いを受ける場合があります。したがって、接続数やワーカー数に基づいて処理能力に関する判断を下す前に、使用中の MPM を確認してください。

ローカルステータスエンドポイントを設定する

変更を行う前に、Apache HTTP Server 2.4 が動作しているかどうかを確認してください。 mod_status が読み込まれており、必要な認証モジュールが利用可能であることを確認してください。また、既存の仮想ホストとアクセスルールも確認してください。モジュールの有効化や設定パスはディストリビューションによって異なります。以下の例は、適切なApache設定ファイル内に記述するものであり、一律に想定されるファイルには記述しないでください。

この例では、 拡張ステータス 明示的に指定し、そのパスをステータスハンドラに割り当てます。 Require local Apacheのローカル接続に関するルールに従ってアクセスを制限します。詳細ログ記録に関するディレクティブは、Locationセクションの外側に配置されています。適用する前に、このセクションが既存の設定とどのように相互作用するかを確認する必要があります。

ExtendedStatus On

<Location "/server-status">
    SetHandler server-status
    Require local
</Location>

変更を適用する前に、自社の運用プロセスに従って確認・承認を受けてください。この例はあくまで参考であり、すべての仮想ホストやプロキシ経路に対して保証するものではありません。特に、既存の認証セクションによって、具体的なリクエストにどのルールが適用されるかが左右される場合があります。

実行後、以下の読み取りコマンドを使用して、機械可読形式の出力をローカルで取得できます。このコマンドを実行するには、指定されたループバックアドレスと標準ポート80にリスナーが設定されている必要があります。 また、リクエストが指定された仮想ホストに到達しているかどうかも確認してください。必要に応じて、ポートやホストの選択を環境に合わせて調整する必要があります。

curl --fail --silent --show-error 'http://127.0.0.1/server-status?auto'

取得に失敗したとしても、それはあくまで一つの手がかりに過ぎず、明確なエラー診断ではありません。認証の問題以外にも、別のリスナー、ホストの割り当て違い、あるいはリダイレクトなどが考えられます。一方、ローカルでの取得に成功したからといって、他のアクセス経路が保護されているかどうかは分かりません。

モニタリングへのアクセス権限を安全に拡張する

アクセス方法については、モニタリングが実行されている場所と、出力を必要とするユーザーに応じて選択してください。同じホスト上のエージェントであれば、ローカル制限を利用できます。外部システムからアクセスする必要がある場合は、アクセス許可を実際に必要なソースに限定し、その後、所定のネットワーク経路を通じて検証を行う必要があります。

時点では Require ip モニタリングサーバーが自身の視点から認識しているアドレスだけが決定的なわけではありません。リバースプロキシの背後では、インストールされた設定が、Apacheが認証のために実際に参照するアドレスを指定している必要があります。 ネットワークを公開する前に、実際の通信経路上でこの対応関係を確認してください。推測されたクライアントアドレスだけでは、信頼性の高いアクセス制御とはなりません。

いくつか Require- セクション内のディレクティブは、適切なコンテナがない場合、原則として 「または」演算子: リクエストが条件のいずれかを満たしていれば、それだけで十分である場合もある。許可されたネットワークからのクライアントが、さらにログインを行う必要がある場合は、その条件を明示的に <RequireAll>-コンテナをまとめて、両方の要件を個別にテストする。

ベーシック認証では、TLS などの適切な通信プロトコルによって初めて、送信中のアクセス情報が保護されます。別途管理ネットワークを設けることで、アクセス範囲をさらに制限することは可能ですが、効果的な Apache の認証機能の代わりにはなりません。そこにおいても、権限のあるシステムのみが HTML 形式および機械可読形式の出力を取得できるようにすべきです。

ステータス値を正しく分類する

ステータスページでは、さまざまな診断に関する質問に対して、それぞれ異なるデータが表示されます。以下の ワーカーの割り当て したがって、これは孤立した情報ではありません。これは、リクエストが取得された時点の状態を表しています。その他のリクエストの詳細は、設定、特にExtendedStatusによって異なります。どのフィールドが表示されるかは、サーバーやMPMによって異なる場合があります。

あるクエリの実行時に、使用中のワーカーが多く、空きワーカーがわずかしかいない場合を想定します。これは一時的な負荷のピークである可能性もあれば、長期にわたる負荷の高まりを示している可能性もあります。 キャパシティの変更を検討する前に、クエリを再度実行し、応答時間、エラー、および実際に適用されているワーカー制限との推移を比較してください。

時点では event-MPM 特定の待機状態は、永続的にバインドされたワーカースレッドではなく、リスナーによって処理される場合があります。したがって、「Writing」や「Keep-alive」は接続状態として捉えるべきであり、単に占有されているスレッドの数として一概に解釈すべきではありません。 また、終了中のプロセスや、グレースフル・リスタート後の古い世代も状況に影響を与える可能性があります。インストールされている 2.4 バージョンの詳細を確認してください。

建築の分類に関しては、以下のものが補足として挙げられる。 Event MPM と Worker MPM の比較 ステータス表示。MPMの選択は、Apacheが接続や処理をどのように管理しているかを説明するものですが、実際のサーバーやそのアプリケーションを監視することに代わるものではありません。

時間経過に伴うステータスデータの推移を観察する

Apacheのモニタリングにおいて、単一のステータスページはあくまで一部に過ぎません。機械可読な出力を ?auto 権限を持つエージェントが定期的に取得し、その値をタイムスタンプ付きで保存します。これにより、空きワーカーの数が少ない状態が短期間だけ発生しているのか、それとも複数のクエリにわたって継続しているのかを把握することができます。

の場合 インターバルレート 累積カウンターの値をその直前の値と比較し、その差を経過時間で割ります。 例えば、60秒間のアクセス数が120増加した場合、この区間における平均アクセス数は1秒あたり2回となります。この平均値だけでは、その1分間のアクセス数の分布については何も示していません。

差分計算を行う前に、起動時または再起動時の情報とカウンターの値を検証してください。サーバーが再起動された場合、または前回の取得時と比較してカウンターの値が減少している場合は、それをリセットとみなして、新しい比較シリーズを開始してください。 2つのカウンター値から算出された負のトラフィックレートは、この場合誤解を招く恐れがあります。また、失敗したクエリについても、推移の中で識別可能である必要があります。

mod_status が出力するサーバー稼働時間に基づく平均値は、一時的な負荷のピークを平滑化します。適切なクエリ間隔で取得された時系列データは変化をより正確に示しますが、2回のクエリの間に発生したイベントを見逃してしまう可能性もあります。 したがって、診断の目的に合わせて間隔を選択し、収集および保存にかかる負荷も考慮してください。

保存されたステータスデータも保護の対象となります。出力内容によっては、リクエスト情報やクライアント情報が含まれている場合があります。エージェント、ストレージ、および分析へのアクセスは、権限のある担当者やシステムに限定してください。また、それぞれの運用目的に応じて、生データおよびそこから導き出された指標をどのくらいの期間保存するかを定めてください。

アクセス状況とエラーメッセージの確認

変更が承認されたら、まず、ローカルのモニタリングエージェントなど、許可されたアクセス元からのアクセスを確認してください。その後、明示的に許可されていないネットワークロケーションから、HTMLページとバリエーションの両方を確認してください。 ?auto. 両者とも、そこでステータスデータを提供してはならない。1か所の拠点のみ、あるいは1つのアクセス経路のみを対象としたテストでは不十分である。

実際にアクセス可能な仮想ホストについて、また必要に応じて、直接接続およびリバースプロキシを経由した接続についても、テストを繰り返してください。 ローカルで成功したからといって、プロキシでも同様の保護が適用されているとは限りません。リダイレクトにも注意してください。重要なのは、アクセス経路の最終段階で機密性の高いステータスデータが出力されるかどうかです。

許可された取得が失敗した場合は、以下の点に加え、 認可 リスナー、アドレス、ポート、および仮想ホストの選択も同様です。プロキシやリダイレクトのルールによって、リクエストが予想とは異なる経路で転送されることもあります。したがって、単一のエラーがあったからといって、アクセスルールが間違っているとか、ハンドラに不具合があるとかを断定することはできません。

既存の設定について、次のような古いアクセスディレクティブがないか確認してください。 Order そして Deny. それらと新しいものとの軽率な混合は Require-ルールは予期せぬ結果をもたらす可能性があります。単一の許可ルールから最終的なアクセス権を推測するのではなく、実際に有効な組み合わせを確認してください。

また、保護されたロケーションが唯一のステータスエンドポイントであるとは限りません。mod_status が読み込まれている場合、そのハンドラは、ディレクトリごとの設定（以下を含む）でも動作します。 .htaccess 利用可能になる可能性があります。そのため、特に共有サーバーにおいて、既存のエントリや許可されている委任設定を確認し、保護されていないハンドラーがこれ以上設定されないようにしてください。

間接的な証拠から経営判断へ

多くのワーカーが繰り返し稼働しており、空きワーカーがごくわずかである場合は、処理能力の逼迫を示唆する兆候ではありますが、まだ原因の証明にはなりません。 この傾向を、応答時間、エラー率、および実際に適用されているワーカーの上限と比較してください。これらの要素を総合的に把握して初めて、ワーカーの稼働状況と顕著な問題の発生が一致しているかどうか、またその問題がどの程度持続的なものであるかが明らかになります。

制限値を引き上げる前に、利用可能なメモリ容量と、対象となるプロセスやスレッドの追加要件を確認してください。同時に、処理に時間がかかる原因も調査してください。並列性を高めたとしても、根本的な原因が解消されないまま、さらなるリソースを消費してしまう可能性があります。したがって、変更は管理された運用プロセスの中で実施し、その後も継続的に監視を行う必要があります。

リクエストの処理が遅い場合、ステータスを繰り返し確認することで、現在処理中のリクエストや関連するプロセスを絞り込むことができます。そのタイミングを、アクセスログやエラーログ、およびアプリケーションとそのバックエンドのデータと照らし合わせて確認してください。 一時的なリクエストは、2回のステータス照会の間に消えてしまうことがあります。単一の表示だけでは、特定のアプリケーションが原因であると確実に特定することはできず、攻撃があったことを立証することもできません。

人目を引く プロセスID さらに、CPUやメモリの使用状況といったOS関連のデータも確認することができます。この照合は追加の手がかりとなるものであり、リクエストやログとの時間軸での照合に代わるものではありません。特に同様の現象が繰り返し発生している場合は、プロセスや、その時点で処理中のリクエストが変化している可能性があることを考慮する必要があります。

event-MPM では、グレースフルリスタート後の終了中のプロセスや古い世代にも注意してください。これらは移行中の状況に影響を与える可能性があります。なお、開いている接続は、必ずしも永続的に占有されているワーカースレッドと同一視できるわけではありません。 このような移行段階から恒久的なキャパシティの決定を導き出す前に、インストールされているApache 2.4バージョンの特性を確認してください。