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

発生日：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:25 | ModSecurity（OWASP CRS）が全件を 403 でブロック 04:15:xx | 並列処理の負荷でApacheワーカーが飽和・httpd 停止 04:20 | chkservd が停止を検知 → httpd 自動再起動 → 復旧 04:20 | LFD が攻撃元IPをCSFに自動登録・ブロック 06:12 | サーバーB に GCP US 別IPから同一パターンのスキャン着弾。LFD 自動ブロック 06:22 | GCP 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分）応答できない状態になりました。 攻撃はサーバーのセキュリティ機能によりすべて自動でブロックされており、 お客様のデータや個人情報への影響はございません。 また、メールの送受信には影響がありませんでした。 その後、自動復旧システムが正常に機能し、現在は通常どおりご利用いただけます。 ご不便をおかけしたことをお詫び申し上げます。 販売開発　営業・サポート　しみず ■ 教訓 ・.git/config スキャンは単発ではなく、複数サーバーに時間差で波状着弾する。1台で発生したらすぐ他サーバーも確認すること。 ・ModSecurityが全件ブロックしても、大量並列接続でワーカーが飽和しhttpdが落ちることがある。「ブロックしてるから安心」ではない。 ・chkservdの自動再起動が機能している限り、停止は数分で復旧する。アラートメールが来ても即座に慌てる必要はない。 ・調査のついでに副次問題（別件のメール認証エラー）を発見できた。定期ログ監視の重要性を再確認。 本レポートはサーバー運用の記録を匿名化・一般化したものです。サーバーIP・ドメイン名・顧客情報は掲載していません。