2026年5月29日、17:04。コートジボワールからの2つのIPアドレスがMultifyプロキシサーバーに接続しました。次の90秒間で、それらはほぼ100のURLを総当たりし、100の拒否を受けました。
これは一般的な脆弱性スキャナーの動作です。標的型攻撃ではなく、自動的な偵察です。このようなスキャナーは、何百万ものサイトを継続的に巡回し、たった1つのものを探しています。それは、キー、パスワード、または設定を含む開かれたファイル、あるいはCMSの既知の脆弱性です。サイトがWordPress、Drupal、Joomla、またはカスタムエンジンで構築されているかは関係ありません。スキャナーは標準的な辞書に基づいてすべてをチェックします。
Multifyはリバースプロキシとして、すべての受信トラフィックを自身で受け取ります。スキャナーはクライアントのサイトに直接ではなく、Multifyのインフラストラクチャにアクセスします。プロキシ保護こそが、クライアントサイトの保護なのです。
スキャナーが探すもの
実際のログからのリストです。
`` /.env /.env.production /.env.local /.env.bak /wp-config.php /config/database.php /config/secrets.yml /azure-credentials.json /gcp-credentials.json /private.key /database.sql /dump.sql ``
これはランダムな組み合わせではなく、実際の情報漏洩から作成された標準的な辞書です。このリストにある各ファイルは、かつて誰かの本番サーバーで公開されていました。
具体的に何を探しているのか
環境変数 — .envファイルとそのバリアント。開発者はAPIキー、データベースパスワード、決済システムトークンをこれらに保存します。このようなファイルが1つあれば、攻撃者は侵入の痕跡を残さずにインフラストラクチャへの完全なアクセスを得ることができます。GitGuardianのデータによると、2024年には公開リポジトリで1,200万回以上シークレットが検出され、.envは最も頻繁に検出されるトップ3に入っています。開発者はファイルを.gitignoreに追加しますが、デプロイ後にサーバーの公開ディレクトリに残され、誰もチェックしません。
CMSとフレームワークの構成 — wp-config.php (WordPress)、Joomla、Drupalの構成、Laravel、Symfony、Railsのファイル。スキャナーはサイトが何で書かれているかを知らないため、すべての一般的なバリアントを順番にチェックします。
クラウドキー — gcp-credentials.json, azure-credentials.json, service-account.json, terraform.tfvars。これらが漏洩すると、すべてのデータと数万ドルに及ぶ可能性のある請求書を含むクラウドアカウントへのアクセスを意味します。
暗号化キー — private.key, server.key, rails/master.key。公開された秘密鍵は、すべてのトラフィックを復号化したり、署名を偽造したりすることを可能にします。
ログとダンプ — error.log, debug.log, database.sql, dump.sql。ログには、ユーザーデータ、ファイルパス、場合によっては平文のパスワードが含まれていることがよくあります。
インフラ構成 — nginx.conf, docker-compose.yml, web.config。これらから、内部ネットワークトポロジを把握し、次のエントリポイントを見つけることができます。
CMSの脆弱性 — は別のカテゴリです。新しいCVEが公開されるとすぐに、スキャナーはすべてのサイトをスキャンし始め、多くの場合数時間以内にスキャンします。Google Project Zeroによると、CVE公開から最初の攻撃までの期間の中央値は15日ですが、公開されたPoCを持つ脆弱性の場合、この時間は数時間に短縮されます。現在活発に悪用されている例： CVE-2026-9082、PostgreSQL上のDrupal CoreにおけるSQLインジェクション（バージョン8.0から11.3.9）。この脆弱性は、DrupalがJSON:APIを介してSQLクエリを構築する方法にあります。攻撃者は、ネストされたSQLを含む配列キーをフィルタパラメータに渡し、Drupalはそれをサニタイズせずにクエリに挿入します。認証なしで、通常のHTTPリクエストを介して実行されます。結果：データベースのダンプ、管理者アカウントの作成、一部の構成では任意のコード実行。CVSS 9.8、クリティカル（比較として、2021年にインターネットの半分をダウンさせたLog4Shellは10.0でした）。パッチは5月20日にリリースされ、動作するPoCは1時間以内にGitHubに登場しました。5月22日、この脆弱性はCISAの既知の悪用された脆弱性カタログに追加されました。最初の48時間で、65カ国の約6,000のサイトで15,000件以上の悪用試行が記録されました。
5月29日の攻撃はまさにそうでした。WAFはOWASP CRSのシグネチャに基づいて動作し、CrowdSecは両方のIPをブロックリストに追加しました。クライアントはこれを知りませんでした。
スキャナーは90秒で一度にすべてのカテゴリをスキャンしました。
2つのIP — 1つのスキャナー
スキャナーは2つのアドレスから同時に起動しました。最新のスキャナーは、単純なレート制限ルールのしきい値を下回るように、複数のIPに負荷を分散します。保護が「1つのIPから1分あたり10を超えるリクエスト」でトリガーされる場合、スキャナーは各IPから5つのリクエストを行うだけです。同時に、IP自体は実際の攻撃者とは関係がないことがほとんどです。これらは、レンタルされたVPS、ハッキングされたサーバー、または世界中のボットネットマシンです。コートジボワールはここではランダムな地理であり、実際に人が働いている場所ではありません。
ログからの興味深い詳細：2番目のIPからの最初の要求は200を返しました。スキャナーは最初にメインページをチェックし、サイトが稼働していることを確認してから、列挙を開始しました。これは、ランダムなトラフィックではなく、ツールの兆候です。
プロキシが攻撃をブロックする方法
WAF
WAF (Web Application Firewall) — アプリケーションレベルのファイアウォール。IPとポートを監視するネットワークファイアウォールとは異なり、WAFはHTTPリクエストのコンテンツ（URL、ヘッダー、本文）を読み取ります。サイトに到達する前に、すべてのリクエストを分析します。
ルールの基礎 — OWASP Core Rule Set (CRS) は、非営利団体OWASPがサポートするオープンな攻撃シグネチャセットです。CRSは、設定ファイルのブルートフォース、SQLインジェクション、XSS、その他の一般的な攻撃ベクトルをカバーします。.env、.sql、.key、wp-config.php、その他数十の拡張子へのリクエストは即座にブロックされます。WAFはファイルがサーバーに存在するかどうかを知りません。リクエスト名に基づいてブロックし、スキャナーは何かを知る前に拒否されます。
CrowdSec
CrowdSec は、オープンな行動分析エンジンです。WAFは各リクエストを個別に処理しますが、CrowdSecはシーケンスを監視します。つまり、このIPが過去数分間に何をリクエストしているかを確認します。
.envへの1つのリクエストはリンクのエラーである可能性があります。30秒以内に.env、.env.production、.env.local、.envrcへの10件のリクエストは、もはやユーザーではありません。CrowdSecは、 シナリオ （行動ルール）に基づいてこのパターンを認識し、IPをブロックします。ブロックされたアドレスは、世界中の何千ものサーバーで使用されている共通の脅威データベースに追加されます。あるサイトで検出されたスキャナーは、すぐにどこでも歓迎されないゲストになります。
数字で見る攻撃
スキャナーは1分半で標準辞書を処理し、何も見つけられませんでした。クライアントのサイトは悪意のあるリクエストを1つも受信しませんでした。
なぜこのように機能するのか
サイトがMultifyに接続されると、すべての受信トラフィックはプロキシを経由します。クライアントはローカライズのためにMultifyを接続しましたが、保護のためではありませんでした。しかし、プロキシがサイトの前に配置されているため、Multifyインフラストラクチャのすべての保護が自動的にサイトに適用されます。
公開ファイルからの情報漏洩は、最も一般的なハッキングベクトルの1つです。これは複雑なエクスプロイトによるものではなく、単純なエラーが原因で発生します。開発者がプロジェクトをデプロイし、.envを削除し忘れたり、テスト用のデータベースダンプを公開フォルダに置いたり、パスワードを含む設定ファイルをサーバーに残したりするケースです。スキャナーは、チームの誰かがエラーに気づくずっと前に、数時間以内にそのようなファイルを見つけます。
よくある質問
MultifyはCVE-2026-9082から保護しますか？
クライアントのサイトがPostgreSQLを搭載したDrupalで動作している場合、プロキシレベルのWAFは、/jsonapiへの複雑なフィルターパラメータ、非標準のボディを持つ/user/login?_format=jsonへのリクエストなど、特徴的なリクエストパターンをブロックします。スキャナーはサイトに到達できません。しかし、これはパッチの代わりにはなりません。プロキシを迂回してサイトに直接アクセスできる場合、保護はありません。
なぜIPが1つではなく2つなのですか？
最新のスキャナーは、単純なレート制限ルールのしきい値を下回るように、複数のアドレスにリクエストを分散させます。CrowdSecは、単一のIPからのリクエスト数ではなく、動作を監視するため、この手法は役に立ちません。
スキャナーはクライアントのサイトについて何か知っていましたか？
いいえ。WAFは、リクエストがアプリケーションに到達する前に、パス名によってリクエストをブロックします。スキャナーは、ファイルがサーバー上に存在するかどうかを知りません。プロキシレベルで拒否されます。
攻撃がスキャナーではなく、標的型攻撃の場合はどうなりますか？
標的型攻撃はより複雑です。攻撃者はターゲットを知っており、標準外のベクトルを使用し、行動パターンに引っかからないようにゆっくりと作業します。WAFとCrowdSecは攻撃対象領域を減らしますが、100%の保証はありません。重要なサイトには、侵入テストと異常監視が必要です。
コートジボワールは重要ですか？
いいえ。スキャナーのIPジオロケーションは、攻撃者ではなく、使用されているマシンのジオロケーションです。国によるブロックは無意味です。次の攻撃はブラジル、オランダ、またはロシアから来るでしょう。