特別公開レポート:Webサーバー一時停止の原因と対応記録

Uncategorized

発生日:2026-06-16 早朝 / 公開:2026-06-16


要点(3行まとめ)

  • GCPクラウドから .git/config 露出を狙う自動スキャン攻撃が複数サーバーに波状着弾した
  • ModSecurityが全件ブロックしたが、大量並列処理の負荷でApacheワーカーが飽和し約5分間停止
  • LFD・ModSecurity・chkservdの三層自動防衛が連携し、人手なしで復旧・ブロック完了

何が起きたか

2026年6月16日早朝、管理下の2台のWebサーバーが相次いで約5分間の一時停止を起こした。 いずれもcPanelのchkservdが自動検知・自動再起動で復旧しており、メール送受信への影響はなかった。

原因はGCP(Google Cloud Platform)の複数IPアドレスから仕掛けられた、Gitリポジトリ露出スキャン攻撃だった。


タイムライン

時刻(JST)出来事
04:15:24〜25サーバーA に GCP US リージョンIPから .git/config 大量並列スキャン着弾
04:15:25ModSecurity(OWASP CRS)が全件を 403 でブロック
04:15:xx並列処理の負荷でApacheワーカーが飽和・httpd 停止
04:20chkservd が停止を検知 → httpd 自動再起動 → 復旧
04:20LFD が攻撃元IPをCSFに自動登録・ブロック
06:12サーバーB に GCP US 別IPから同一パターンのスキャン着弾。LFD 自動ブロック
06:22GCP KR リージョンIPからも着弾。LFD 自動ブロック
06:41サーバーB でも httpd 停止 → chkservd 自動再起動 → 復旧

2台が別々の時間帯に同一の攻撃を受けており、同一キャンペーンによる波状攻撃と推定される。


攻撃の内容

何を狙っていたか

.git/config ファイルはGitリポジトリの設定ファイルで、公開状態だとリモートリポジトリのURLや認証情報が漏洩する。自動ツールがWebサーバー上の典型的なディレクトリを総当たりでスキャンしていた。

スキャンされたパスの例:

/.git/config
/laravel/.git/config
/wordpress/.git/config
/wp-content/.git/config
/admin/.git/config
/shop/.git/config
/code/.git/config
/project/.git/config
(他多数)

なぜhttpdが落ちたか

ModSecurityはリクエスト1件ごとにOWASP CRSの全ルール(数百件)を評価する。通常は問題ないが、短時間に約15の並列接続が殺到したことで、ルール評価のCPUコストが重なりApacheのワーカープロセスが飽和した。

攻撃着弾(大量並列)
  └─ ModSecurity が各リクエストを評価・403 ブロック
       └─ ルール評価コストがワーカー数(150)を圧迫
            └─ httpd が新規接続を受け付けられなくなり停止
                 └─ chkservd が検知 → 自動再起動 → 復旧

実害はなかったか

項目状況
情報漏洩なし(.git/config は存在しないパスへのアクセスのため)
Webサイト停止中(約5分間)は接続不可
メール送受信影響なし(Dovecotは別プロセスのため継続稼働)
データ改ざんなし

自動防衛の連携

今回は人手を介さずに3つの仕組みが連携して機能した。

① ModSecurity(OWASP CRS)
   → 攻撃リクエストをすべて 403 ブロック。情報漏洩ゼロ。

② LFD(Login Failure Daemon)
   → 閾値を超えた攻撃元IPをリアルタイム検知・CSF deny に自動登録。
   → 次の波状攻撃を事前遮断。

③ chkservd(cPanel サービス監視)
   → httpd の停止を自動検知・再起動。
   → 復旧まで約5分。アラートメールも自動送信。

3層すべてが設計通りに機能した好例として記録する。


なぜこの攻撃が来るのか

.git/config スキャンは世界中のサーバーに日常的に仕掛けられる定番攻撃のひとつ。
クラウド(GCP・AWS・Azure等)の仮想マシンを使い捨て感覚で使い、IPアドレスを変えながら複数サーバーに波状攻撃を仕掛けるのが典型的なパターン。

今回 Azure からのPHPスキャン攻撃も別サーバーで同日に422,000件以上確認しており、組織的な攻撃活動の一環と見られる。


再発への備え

今回の自動防衛は機能したが、攻撃規模が大きくなれば再び停止が起きる可能性はある。中長期的な対策として以下を検討する。

  • ModSecurity のルール最適化:不要なルール評価を減らしCPUコストを下げる
  • Apache の MaxRequestWorkers 調整:ワーカー数の上限を環境に合わせて見直す
  • 攻撃元IPレンジのCSFブロック:GCP・Azureのクラウドレンジを事前にブロックする(誤検知との兼ね合いに注意)

ユーザーへの説明文(テンプレート)

問い合わせがあった場合、以下を参考に案内する。

本日早朝、外部からの不正アクセス試行(Webサーバーへの自動スキャン攻撃)を受け、 サーバーが短時間(約5分)応答できない状態になりました。

攻撃はサーバーのセキュリティ機能によりすべて自動でブロックされており、 お客様のデータや個人情報への影響はございません。 また、メールの送受信には影響がありませんでした。

その後、自動復旧システムが正常に機能し、現在は通常どおりご利用いただけます。 ご不便をおかけしたことをお詫び申し上げます。

販売開発 営業・サポート しみず


教訓

  1. .git/config スキャンは単発ではなく、複数サーバーに時間差で波状着弾する。1台で発生したらすぐ他サーバーも確認すること。
  2. ModSecurityが全件ブロックしても、大量並列接続でワーカーが飽和しhttpdが落ちることがある。「ブロックしてるから安心」ではない。
  3. chkservdの自動再起動が機能している限り、停止は数分で復旧する。アラートメールが来ても即座に慌てる必要はない。
  4. 調査のついでに副次問題(別件のメール認証エラー)を発見できた。定期ログ監視の重要性を再確認。

本レポートはサーバー運用の記録を匿名化・一般化したものです。サーバーIP・ドメイン名・顧客情報は掲載していません。

タイトルとURLをコピーしました