はじめに
前回の記事で、重大な脆弱性が出た週に、何を見て、何を決めたかを書きました。最後に、「次回は、要対応となったサーバーの顛末を、お届けする予定です」と書きました。この記事が、その続きです。
結論から書きます。
- 更新の前に、WAFを前倒しで入れました。 本来は、更新と同じタイミングで、入れる予定でした。
- 更新は、予定どおりに進み、問題なく運用できています。
- WAFは、カウント(記録だけ)からブロックへ、土日のアクセスログを見ながら切り替えました。 日曜日の夕方に、ブロックにしました。
- ただし、WAFは、暫定の緩和策です。 根本の対策は、更新です。PHPの公式も、「完全な緩和策はなく、更新が唯一」としています。
会社や製品が特定されないよう、社名、製品名、構成の詳細は書きません。
前回までのおさらい
- 10月22日に、上司から「うちは大丈夫?」と聞かれ、調査をしました。
- 要対応になったのは、インターネットから使える、社内向けのグループウェアでした(製品名は書きません)。
- 保守ベンダーが、更新版を提供するまでには、時間がかかる状況でした。
- 更新は、もともと別の理由で、10月26日(月)に予定していました。その更新の時に、WAFも入れる予定でした。
つまり、10月22日から、更新予定日の26日までの数日間を、どう守るかが、問題でした。
10月23日の判断:WAFを、更新より先にする
「更新まで待つ」か、「更新の前に、できることをやる」か。後者を選びました。
- 即時停止は、業務への影響が大きく、難しい。
- 社内利用のサーバーで、一般のユーザーには周知していません。 ただ、これは「安全」の根拠には、なりません。無差別に探索する攻撃が、多いからです(マクニカも、「無差別な攻撃の可能性が高い」としています)。
- 現行の仕組みだけでは、不十分。 更新を待つ間、何も防御がない状態になります。
- 一方で、WAFは、もともと入れる予定だったので、前倒しなら、設計の考え方は、変わりません。
この判断を、上司に報告し、承認を得て、進めました。
WAFの構成
クラウド環境で運用していたので、ロードバランサーの前段に、WAFを置きました。 ルールは、次の3つを組み合わせました。
- マネージドルール(PHP用): PHP2Shellに対応したルールが、WAFの提供元から、提供されています。
- 地理(Geo)による制限: 業務で使わない地域からのアクセスを、制限しました(具体的な内容は、書きません)。
- JPCERT/CCが公開した、最近の攻撃に使われた、送信元IP 25件の制限: JPCERT-AT-2026-0030に、掲載されています。10月23日の更新で、25件になりました。
マネージドルールについて(提供元の公式情報で確認)
WAFの提供元は、PHP用のマネージドルールに、PHP2Shellの対策を、追加しています。
- CVE-2026-109619向けの検知(
PHP2Shell_BODY)が、10月21日に追加されました。 - CVE-2026-109618向けの検知(
PHP2Shell_BODY_Extended)が、10月22日に追加されました。その後、両方の検知が改善されています。 - 既定のバージョンを使っていれば、自動で保護されます。バージョンを固定している場合は、最新に上げる必要があります。
- 「ルールが、カウントに上書きされていないか」も、確認のポイントです。
(出典: 提供元のセキュリティ情報と、マネージドルールの変更履歴。確認日 10月25日)
提供元自身が書いている「限界」
提供元の公式ブログは、WAFの限界を、自分で書いています。ここは、大事なところです。
- PHPの更新が、唯一の完全な対策です。
- WAFは、multipart(ファイルの送信形式)の内部までは、解析しません。サーバー側のメモリや設定は、見えません。
- ボディを検査する量には、上限があります。サイズの上限内で、小さなヘッダーを大量に送る攻撃は、防げません。
- アップロード機能を使っているアプリでは、WAFは、リスクを下げるだけです。
なので、WAFだけで「安心」とは、考えていません。更新までの、つなぎです。
土日の運用:カウントから、ブロックへ
ここが、実際の運用の、いちばん手間のかかった部分でした。
提供元の公式も、まずカウントで確認し、そのあと、ブロックにすることを、すすめています。ただ、今回は、更新予定日(10月26日・月曜日)まで、時間がありません。
- 土日の、実際の業務のアクセスを、ログで確認しました。平日の業務時間帯ではなく、土日の実運用のアクセスを、見ることになります。
- ログは、3〜4時間おきに確認しました。
- 業務のアクセスと思われるものが、ブロックの対象になりそうなルールは、カウントに変更する、といった対応をしました。
- そのうえで、日曜日(10月25日)の夕方に、PHP用のルールを、ブロックにしました。
「平日の業務時間のアクセス」を、見られないまま、ブロックにしたことになります。月曜日の朝に、業務へ影響が出ていないかを、確認することも、前提でした。
月曜日の朝の時点で、業務への影響は、ありませんでした。 あわせて、WAFのログとWebサーバーのログを確認しました。判断できる限りでは、侵入の形跡は、ありませんでした。
更新予定日:グループウェアの更新
更新は、もともと予定していたバージョンアップに、脆弱性対応版の適用を、足す形で進めました。
- 予定していたバージョンアップは、グループウェアの製品のライフサイクル上、必須のものでした。
- 適用したのは、開発元が案内した、脆弱性の対応版です。
- 適用の手順そのものは、バージョンアップと同じ手順でした。そこで、リハーサルは、省きました。
- 代わりに、もともとのバージョンアップの予定の時点で、スナップショットを取り、そこに脆弱性対応版を適用し、何かあれば、ロールバックする方針にしました。
この結果、適用後は、特に問題なく、運用できています。
今回は、条件に恵まれていた
正直に書くと、今回は、条件に恵まれていました。
- バージョンアップは、もともと必須で、予定されていた。
- WAFも、昨今のサイバー攻撃への備えとして、導入する予定で、検証は完了していた。
- 今回、未検証だったのは、脆弱性対応版へのバージョンアップの部分だけだった。
もし、突発的なPHPの脆弱性だけが起きていたら、1週間程度の準備と検証の時間が、必要だったと思います。
つまり、今回は、平時に準備していたこと(別の理由で予定していた作業)が、そのまま緊急対応の土台になりました。
更新後
- WAFは、今後も残します。 更新後も、多層防御として、意味があります。
- 侵害調査は、前回書いたとおり、JPCERT/CCが公開した攻撃元の25件のIPと、海外からのアクセスを中心に、ログを確認しました。25件のIPは、記録がなく、海外からのアクセスは、ありましたが、ログインが成功した形跡は、ありませんでした。 更新の前後のログ確認でも、判断できる限りでは、侵入の形跡は、ありませんでした。 ただし、痕跡がないことが、攻撃がなかったことの証明には、なりません。
学び
- 暫定策は、「入れて終わり」ではなく、「運用」が必要。 カウントからブロックへの切り替えは、ログを見る人の手間が、そのまま品質になります。
- 平日の業務のアクセスが見えない場合は、土日のログと、頻度の高い確認で、補う。 ただし、これは、完全ではありません。翌日の確認が、前提です。
- IPの制限は、補助。 攻撃元は、変わります。IPの制限は、あくまで、補助的な層です。
- WAFの限界を、公式の説明で、把握しておく。 「入れたから大丈夫」は、危険です。
- 一次情報で、効果と限界を、確かめる。 今回は、提供元の公式の説明を、先に確認しました。
- 更新が、唯一の完全な対策。 WAFは、更新までの、時間を稼ぐ道具です。
- 別の理由で予定していた作業が、緊急対応の土台になった。 今回は、必須のバージョンアップと、WAFの導入が、すでに予定され、検証も進んでいました。そのおかげで、未検証だったのは、脆弱性対応版の部分だけでした。突発的な脆弱性だけだったら、1週間ほどの準備と検証が、必要だったと思います。緊急時の速さは、平時の準備の量で決まる、と実感しました。
- リハーサルを省く判断は、手順の同一性と、ロールバックの用意が、条件。 今回は、バージョンアップと同じ手順で、スナップショットを取り、戻せる状態にしてから、適用しました。「同じ手順だから省く」は、戻せることが、前提です。
前回の記事: 重大な脆弱性が出た週、実際に何を見て、何を決めたか
出典
コメント