攻撃の分析：脆弱性スキャナー対Multifyプロキシ

2026年5月29日、17:04。コートジボワールからの2つのIPアドレスがMultifyのプロキシサーバーに接続しました。次の90秒間で、彼らは約100のURLを試行し、100回の拒否を受けました。

これは脆弱性スキャナーの典型的な動作です。標的型攻撃ではなく、自動的な偵察です。このようなスキャナーは、キー、パスワード、または設定を含む公開ファイル、あるいは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年には公開リポジトリで1200万回以上シークレットが発見され、.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 Known Exploited Vulnerabilitiesカタログに追加されました。最初の48時間で、65か国の約6,000のサイトで15,000件以上の悪用試行が記録されました。

5月29日の攻撃はまさにそうでした。WAFはOWASP CRSのシグネチャに基づいて動作し、CrowdSecは両方のIPをブロックリストに追加しました。クライアントはこれを知りませんでした。

スキャナーは90秒で一度にすべてのカテゴリをスキャンしました。

スキャナーは2つのアドレスから同時に起動しました。最新のスキャナーは、単純なレート制限ルールのしきい値を下回るために、負荷を複数のIPに分散します。「1つのIPから1分あたり10リクエスト以上」で保護がトリガーされる場合、スキャナーは各IPから5リクエストずつ実行します。同時に、IP自体は実際の攻撃者とはほとんど関係ありません。これらはレンタルされたVPS、ハッキングされたサーバー、または世界中のボットネットマシンです。コートジボワールはここでは偶然の地理であり、実際に人が働いている場所ではありません。

ログからの興味深い詳細：2番目のIPの最初の要求は200を返しました。スキャナーは最初にホームページをチェックし、サイトが稼働していることを確認してから、列挙を開始しました。これはランダムなトラフィックではなく、ツールの兆候です。

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 はオープンソースの行動分析エンジンです。WAFは各リクエストを個別に処理しますが、CrowdSecはシーケンスを監視します。つまり、過去数分間にこのIPが何をリクエストしているかを監視します。

.envへの1つのリクエストはリンクのエラーである可能性があります。30秒以内に.env、.env.production、.env.local、.envrcへの10件のリクエストは、もはやユーザーではありません。CrowdSecは、 シナリオ （行動ルール）に基づいてこのパターンを認識し、IPをブロックします。ブロックされたアドレスは、世界中の何千ものサーバーで使用されている共通の脅威データベースに追加されます。あるサイトで検出されたスキャナーは、すぐにどこでも歓迎されないゲストになります。

スキャナーは1分半で標準辞書を処理し、何も得られませんでした。クライアントのサイトは悪意のあるリクエストを1つも受け取りませんでした。

サイトがMultifyに接続すると、すべての受信トラフィックはプロキシを介して行われます。クライアントは保護のためではなく、ローカライズのためにMultifyを接続しました。しかし、プロキシがサイトの前に配置されているため、Multifyインフラストラクチャのすべての保護が自動的にサイトに適用されます。

公開ファイルからの漏洩は、最も一般的なハッキングベクトルの1つです。これらは複雑なエクスプロイトではなく、開発者がプロジェクトを展開して.envを削除し忘れたり、テストデータベースダンプを公開フォルダに置いたり、パスワードを含む設定ファイルをサーバーに残したりするなどの単純なエラーが原因で発生します。スキャナーは、チームの誰かがエラーに気づくずっと前に、数時間以内にこのようなファイルを見つけます。

クライアントのサイトがPostgreSQLを搭載したDrupalで動作している場合、プロキシレベルのWAFは、/jsonapiへの複雑なフィルターパラメータ、非標準のボディを持つ/user/login?_format=jsonへのリクエストなど、特徴的なリクエストパターンをブロックします。スキャナーはサイトに到達できません。しかし、これはパッチの代わりにはなりません。プロキシを迂回してサイトに直接アクセスできる場合、保護はありません。

最新のスキャナーは、単純なレート制限ルールのしきい値を下回るように、複数のアドレスにリクエストを分散させます。CrowdSecは、単一のIPからのリクエスト数ではなく、動作を監視するため、この手法は役に立ちません。

いいえ。WAFは、リクエストがアプリケーションに到達する前に、パス名でリクエストをブロックします。スキャナーは、ファイルがサーバーに存在するかどうかを知りません。プロキシレベルで拒否されます。

標的型攻撃はより複雑です。攻撃者はターゲットを知っており、非標準のベクトルを使用し、行動パターンに引っかからないようにゆっくりと作業します。WAFとCrowdSecは攻撃対象領域を減らしますが、100％の保証はありません。重要なサイトには、侵入テストと異常監視が必要です。

いいえ。スキャナーのIPジオロケーションは、攻撃者ではなく、使用されているマシンのジオロケーションです。国によるブロックは無意味です。次の攻撃はブラジル、オランダ、またはロシアから来るでしょう。