2026年1月20日、筆者が管理するサーバにて、典型的な Open Proxy スキャニング（公開プロキシ探索攻撃） を検知しました。
WAF（ModSecurity）が、いかにして「身勝手な中継依頼」を門前払いしたか、実際のログからそのメカニズムを記録します。

1. 検知ログの概要（実録）

以下は、攻撃者が CONNECT メソッドを使用して外部ドメイン（www.baidu.com）へ接続しようとした際のログです。

[Tue Jan 20 05:43:59 2026] [security2:error] [client xx.xx.xx.xx] 
ModSecurity: Warning. Match of "within %{tx.allowed_methods}" against "REQUEST_METHOD" required. 
[id "911100"] [msg "Method is not allowed by policy"] [data "CONNECT"] [severity "CRITICAL"]
[hostname "www.baidu.com"] [uri "/"]

2. 攻撃の構造解析：何が起きていたのか？

このログから、攻撃者の明確な意図が読み取れます。

A. メソッドの悪用（CONNECT）

通常、Web閲覧（GET/POST）には使われない CONNECT メソッドが使用されています。これは本来、プロキシサーバに対して「外部サーバへのトンネルを作れ」と命じるためのコマンドです。

B. Hostヘッダの偽装

[hostname "www.baidu.com"]

攻撃者は、筆者のサーバに接続していながら、リクエストの宛先に www.baidu.com を指定しています。これは、筆者のサーバを「踏み台（Open Proxy）」にして、中国の検索エンジンにアクセスしようとする試みです。

これは、ほぼ、金盾の影響下にある者が当局の規制を逃れるため、私のvpsを利用しようとしたという背景でしょう。

3. 防御のロジック：なぜ止まったのか

ID 911100 の発動: ModSecurity CRS は、許可リストにないメソッド（CONNECT）を検知した瞬間、問答無用で CRITICAL 判定を下しました。

4. 結果：404ページへの誘導。

また、筆者のapacheのバーチャルサイトの設定もいい動きをしました。

ErrorDocument 403 404.html

としていたため、ModSecurity がアクセスを拒絶した後、Apache は設定された ErrorDocument に従い、403 forbiddenではなく、内部的に 404 not found を返しています。
攻撃者側から見れば、外部へのトンネルが開通するどころか、「そんなページ（機能）は存在しない」 という素っ気ない返答を掴まされて終わったことになります。

5. まとめ

今回の事例は、WAFのポリシーを「必要なものだけを許可し、不要なものは拒否する」状態に保ったことが防御につながった例です。

オレだけが外に出る事を
許可しろォォォ─────ッ

だが！
ウイルスは
許可しないィィィ────ッ

感染した部分は
出る事は
許可しないィィィィィ───ッ！！

というイルーヅォの言葉は割とセキュリティで重要という言葉を以て、本記事を締めくくります。