APWG は、2026 年第 1 四半期だけで 971,181 件のフィッシング攻撃 を確認しました。前四半期比で 13.8% 増です。さらに 2026 年 1 月には、Google が、1 週間で 550 を超える脅威グループがトラフィックを流していたことを突き止め、いわゆる 世界最大級の住宅系プロキシネットワークの一つ を無力化しました。つまり、プロキシはフィッシング対策の「敵」にも「味方」にもなり得るのです。
この両面性こそ、"プロキシとフィッシング" を扱う多くの記事が見落としているポイントです。多くの記事は「プロキシは盾だ（うちのプロキシ製品を買えば安全）」と言うか、「プロキシは攻撃者の武器だ（危険だから怖がれ）」のどちらかに偏っています。現実はもっと複雑で、だからこそ面白いのです。
攻撃者は、プロキシ基盤を使って発信元を隠し、信頼されている IP を次々に切り替え、MFA を通過したあとでも認証済みセッションを盗みます。一方、防御側は、怪しいリンクを安全に調査したり、国ごとにフィッシングページの見え方を確認したり、自社サイトに到達する前に悪意あるトラフィックをふるい落としたりするためにプロキシを使います。このガイドでは、攻撃と防御の両面を整理したうえで、実際に導入できる具体的なワークフローまで解説します。机上の空論でも、万能薬でもありません。
- 難易度: 中級
- 所要時間: 読了と計画に約 25 分。実装時間は手順により異なります
- 必要なもの: 自社 Web インフラの基本知識、ドメインの DNS 設定にアクセスできる権限、Chrome ブラウザ（Thunderbit の手順で使用）、必要に応じてプロキシ提供事業者のアカウント
フィッシングとは何か？なぜ企業が警戒すべきなのか？
フィッシングは、相手をだまして情報を奪う攻撃です。犯罪者は、メール、SMS、偽のログインページ、QR コード、なりすましサイトなどを使って、認証情報の入力、ログイン承認、マルウェアのインストール、送金を促します。
もはや「怪しいメールが来る」だけの話ではありません。現在のフィッシングは、クラウド上に置かれた偽ページ、Microsoft 365 の偽ログインフロー、QR コード、セッショントークンの窃取まで含みます。
企業にとって被害は非常に現実的です。IBM の 2025 年版データ侵害コスト調査では、世界平均の侵害コストは 440 万米ドル とされています。FBI の 2025 年版 Internet Crime Report によると、IC3 には約 45.3 万件のサイバー犯罪関連詐欺の申告が寄せられ、報告された損失は 177 億米ドル超 に達しました。そのうち Business Email Compromise（BEC）だけで 30 億米ドル超を占めています。
認証情報の盗難、送金詐欺、サプライチェーン侵害、規制違反による罰金――フィッシングは、こうしたあらゆる被害の入口になり得ます。
以下では、プロキシが攻撃と防御の両方でどう使われるのか、そして多層防御として何をすべきかを、実務ベースで見ていきます。
プロキシの二面性：防御の盾にも、攻撃の武器にもなる
プロキシとは、端末とインターネットの間に入る仲介役です。Web サイトからは、あなたの本当の IP ではなく、プロキシの IP が見えます。郵便の転送サービスのようなもので、相手には自宅住所ではなく転送先の住所から手紙が届くイメージです。
この性質が、いわゆるデュアルユースの問題を生みます。セキュリティチームは、企業の IP や端末を露出させずに脅威を調べるためにプロキシを使います。攻撃者は同じ技術を使い、悪意ある通信を一般ユーザーの通信、別の国からのアクセス、あるいは信頼された家庭用ネットワークからのアクセスに見せかけます。Barracuda の 2026 年 4 月の分析 が端的に説明しているように、住宅系 IP は実在する家庭や小規模事業者の回線に紐づいているため、詐欺検知システムに怪しまれにくいのです。
多くの競合記事は片側しか扱いません。その結果、読者には不完全な理解しか残らず、防御策も不十分になります。
攻撃者はプロキシをどう使うのか
企業の防御担当が特に注意すべき攻撃ベクトルは、大きく 3 つあります。匿名化と IP ローテーション、住宅系プロキシの悪用、そして信頼されたプラットフォームを使った回避です。
AiTM（Adversary-in-the-Middle）フィッシングとは？
AiTM は、「MFA があれば大丈夫」という前提を壊す攻撃です（先に言うと、従来型 MFA では防げません）。
AiTM 攻撃では、攻撃者が被害者と正規のログインページ――たとえば Microsoft 365――の間にリバースプロキシを挟みます。ユーザーには本物のログイン画面に見えます。そこで認証情報を入力し、MFA も完了すると、正規の IdP からセッション Cookie が発行されます。しかし、通信がすべて攻撃者のプロキシを通るため、そのセッション Cookie も攻撃者に抜き取られます。あとは、その Cookie を再利用してアカウントに侵入できてしまいます。パスワードも MFA も、再入力は不要です。
主要な AiTM フィッシングキットの一つである Microsoft による Tycoon2FA の分析 では、運用者が Microsoft 365、Outlook、SharePoint、OneDrive、Google のログインページを偽装できることが示されています。このキットは PDF や QR コードを生成し、リダイレクトの連鎖を管理し、MFA の使用状況やセッション Cookie の取得状況も追跡します。さらに、短命なサブドメインと Cloudflare ホストの基盤を使い、ブロックリストをかいくぐろうとします。
これは机上の話ではありません。AiTM キットはすでに大規模に悪用されており、「MFA を入れています」だけではフィッシング対策として不十分な最大の理由になっています。
住宅系プロキシの悪用と IP ローテーション
住宅系プロキシネットワークは、攻撃者の通信を実在する家庭用 IP 経由に流し、フィッシング要求を正規の利用者に見せかけて、IP ベースの不正検知をすり抜けます。多くの事業者は IP の使われ方を厳密に確認しておらず、グレーな市場ができています。
最も具体的な例が、2026 年 1 月に Google Threat Intelligence Group が IPIDEA の住宅系プロキシネットワークを無力化した件 です。これにより、利用可能な端末プールは数百万規模で減少しました。GTIG は、7 日間の間に 550 を超える個別の脅威グループが IPIDEA の出口ノードを使っていたことを観測しています。調査では、ボットネット、SaaS アクセスの悪用、パスワードスプレー攻撃、世界規模の諜報活動との重なりも確認されました。多くのプロキシ SDK の導入では、明確なユーザー同意が欠けていました。
FBI による 2026 年の住宅系プロキシ警告 では、フィッシング、盗まれた認証情報でのログイン、ブルートフォース攻撃、アカウント乗っ取り、スパム、C2 の難読化などが犯罪用途として列挙されています。
信頼されたプラットフォーム上でのホスティングとフィッシングキットの回避
もう一つの回避手口は、SharePoint、Google Docs、Azure Blob Storage など、信頼度の高いプラットフォーム上にフィッシングページを置き、ドメインの信用を借りる方法です。Microsoft による Azure Blob Storage の脅威分析 でも、攻撃者が偽の Microsoft サインインページをホストし、証明書だけでは悪意のあるページだと見抜きにくくしていることが示されています。
フィッシングキット自体にも回避ロジックが組み込まれています。Cofense のフィッシングキット分析 では、位置情報フィルタリング、ユーザーエージェントや言語の判定、CAPTCHA、開発者ツールの検知、正規ページへのリダイレクトが確認されています。訪問者が想定被害者に合致しない場合――国が違う、ブラウザが違う、あるいはセキュリティスキャナに見える――ページは無害な内容か 404 を返します。
単一の社内 IP やクラウドのデータセンターからのスキャンでは、こうしたページは見逃されます。キット自体が、あなたから隠れるように設計されているからです。
防御側はプロキシをどう活用するのか
防御の側では、プロキシは主に 4 つの役割を担います。
-
匿名 URL／ドメインスキャン。 怪しいリンクを制御されたプロキシ経由で開き、企業の端末や社内ネットワークではなく、プロキシの IP を宛先に見せます。これにより、直接的なリスクを下げ、再現性の高い調査手順を作れます。
-
脅威インテリジェンス収集。 ローテーション型プロキシを使って、フィッシング基盤、ドメイン一覧、公開脅威フィード、新規登録ドメインのソースを継続的に収集し、少数のリクエストでブロックされるのを避けます。（もちろん、法令と利用規約の範囲内で行う必要があります。）
-
地域分散型のフィッシング検知。 複数地域のプロキシを使うことで、怪しい URL が米国、EU、APAC、または他のターゲット市場から見たときに違う挙動をするか確認できます。これは、前述のジオフェンシングやユーザーエージェント判定を使うキットを検出するのに有効です。
-
リバースプロキシ／WAF の導入。 リバースプロキシは自社ドメインの前面に配置します。従業員が外向きのフィッシングリンクをクリックすること自体は止められませんが、自社の Web 資産をボット、クレデンシャルスタッフィング、悪意あるペイロード、異常なトラフィックから守れます。
なぜ MFA だけではプロキシ型フィッシングを防げないのか
IT フォーラムでは何度も同じやり取りを見ます。「MFA を入れているから大丈夫です」と。しかし、実際に AiTM 事案を扱ったシステム管理者の見方はまったく違います。
仕組みは単純です。被害者は本物そっくりのログインフロー上で MFA を完了します。すると、正規の IdP はセッショントークンを発行します。攻撃者はリバースプロキシ経由でそのトークンを回収します。
認証は成功しています。ですが、その瞬間に攻撃者がセッションを乗っ取っているのです。アクティブなセッションや、攻撃者によって変更された MFA 設定が残っている場合、パスワードを変えるだけでは不十分なことがあります。Microsoft も明言している ように、影響を受けた組織は標準的な復旧対応に加えて、セッションクッキーの無効化と、攻撃者が加えた MFA 変更の巻き戻しが必要です。
SMS コード、OTP アプリ、プッシュ承認――これらも、攻撃者が管理するフローの中で入力させられれば盗まれます。MFA は仕事をしています。問題は、攻撃者がその全工程を監視していたことです。
AiTM フィッシングを実際に止めるもの
FIDO2 / パスキー。 FIDO Alliance によれば、パスキーは設計段階からフィッシング耐性を持っています。盗むパスワードがなく、再利用できるサインイン情報もありません。暗号鍵ペアは正規ドメインのオリジンに紐づくため、攻撃者のプロキシではチャレンジを再現できません。CISA も 、FIDO と PKI は、広く利用可能な非独自方式の中で、認証情報のフィッシングを防げる数少ない MFA だと確認しています。
証明書ベース認証。 導入はやや複雑ですが、ユーザーが入力するコードではなく端末証明書に依存するため、同様にフィッシングに強い方式です。
Conditional Access ポリシー。 Microsoft 環境では、Conditional Access によって、準拠端末、信頼済みロケーション、リスクベースのチェック、フィッシング耐性のある認証強度を要求できます。仮に攻撃者がセッショントークンを奪っても、その価値を大きく下げられます。
これらはプロキシの代わりではなく、補完関係にあります。狙うべきは多層化です。
予算が限られた SMB 向けの現実的な選択肢
「Intune、MDM、ハードウェアキーなんて、エンタープライズ向けの予算が必要では？」という反論はもっともです。そこで、低コストで始めるなら次の順です。
- ブラウザ内蔵のパスキーを使う。 いまの主要ブラウザは、ほとんどがパスキーに標準対応しています。追加のハードウェア購入は不要です。まずは管理者、経理、人事のアカウントから始めましょう。
- 無料で DMARC を導入する。 SPF、DKIM、DMARC の各レコードは、公開自体に費用はかかりません。Google Workspace と Microsoft 365 には、設定ガイドも用意されています。
- 防御用ドメインを確保する。 ブランド名の綴り違いや類似ドメインをあらかじめ取得しておきます。多くのレジストラは 1 ドメインあたり年 10～15 ドル程度です。それぞれに DMARC の reject ポリシーを設定しましょう。
- 重点的な教育を行う。 特に AiTM を狙った誘導――偽の Microsoft 365 ログインページ、偽のドキュメント共有、QR コード、device code 詐欺、「至急の給与／取引先対応」系のフロー――に絞って啓発します。
要するに、「まず始めて、あとで強化する」という考え方です。部分的な導入でも、リスクはかなり下げられます。
フィッシング対策に最も向いているプロキシはどれか？
プロキシの種類によって、向いているフィッシング対策は異なります。選び方を誤ると、コストが無駄になったり、検知漏れが増えたりします。
| プロキシの種類 | 最適なフィッシング対策用途 | メリット | デメリット | コスト感 |
|---|---|---|---|---|
| データセンター | 大量 URL スキャン、ドメイン監視 | 高速、低価格、大量処理向き | 高度なフィッシングキットには見抜かれやすい | 低 |
| 住宅系 | 地域別のフィッシング検知、利用者視点のテスト | 実ユーザーの通信に見える、ジオブロックを回避しやすい | 遅め、割高、倫理面のソース確認が重要 | 高 |
| ローテーション型 | 脅威インテリジェンス収集、継続監視 | 長時間のクロールでも IP ブロックを回避しやすい | 構成がやや複雑、遅延が安定しないことがある | 中 |
| リバースプロキシ / WAF | 自社 Web 資産の防御 | 入口の脅威を遮断、ボット検知、DDoS 対策 | 外向きフィッシングの検知には使えない | 中 |
倫理的なソース調達について。 Google/IPIDEA の件と FBI の警告が示す通り、住宅系プロキシネットワークは、侵害端末、欺瞞的な SDK、隠れた VPN 条項、マルウェアなどで構築されている可能性があります。住宅系プロキシの通信を購入する前に、提供事業者に対して、明確なユーザー同意、オプトアウト手段、監査可能性、乱用対応の仕組みを必ず確認してください。セキュリティ研究で以前問題視された事業者（PacketStream、現在は終了した 911 Proxy など）は、特に慎重に扱うべきです。
多くの中小企業では、まずデータセンタープロキシで大量スキャンを行い、自社ドメインにはリバースプロキシ/WAF を導入するのが現実的です。住宅系プロキシは、地域別の検証が必要で、かつ提供元をしっかり精査できる場合に限って追加しましょう。
実践編：プロキシでフィッシングを避ける手順
多くの記事は理論で終わります。以下の各ステップでは、使うべきツールと、IT チームに渡せるレベルの具体性まで落とし込んでいます。
ステップ 1：新規登録された類似ドメインを監視する
攻撃者は、キャンペーンを始める前に、あなたのブランドに似たドメインを取得します。たとえば thunderb1t.com、thunderbit-login.com、thunderbit-support.net です。
こうしたものを早く見つけることは、非常に価値の高い防御策の一つです。
やり方:
- ブランド名、製品名、役員名、そしてログイン関連の語（例: "login"、"portal"、"invoice"、"payment"）を監視対象リストに入れます。
- crt.sh を使って、Certificate Transparency（CT）ログを毎日検索します。ドメイン名や組織名で証明書レコードを検索できます。CT ログには公開信頼された証明書が記録されるため、類似ドメインの新規証明書がここに現れます。
- ブランドとの編集距離が近いもの、怪しい TLD（.xyz、.top、.click など）、ログインや支払い関連キーワードを含むものをフラグします。
- フラグしたページは、社員のブラウザではなく、必ずプロキシやサンドボックス経由で表示します。
Thunderbit との連携: Thunderbit の一括抽出 API を使うと、1 ジョブあたり最大 100 件の怪しい URL を処理でき、renderMode: "full" で JavaScript の多いフィッシング偽装ページもレンダリングできます。取得したいデータの JSON Schema を定義しておけば、ページタイトル、ログインフォームの有無、フォーム送信先ドメイン、SSL 発行者、リダイレクトの連鎖、最終 URL などを構造化して回収できます。CLI 版なら、cron ベースの監視にもきれいに組み込めます。
thunderbit batch extract --file suspicious-urls.txt --schema phishing-signals.json --render-mode full
非技術者であれば、Thunderbit の Chrome 拡張 を使って、数クリックで怪しいページを素早く抽出・確認することもできます。数本の URL を目視したいだけなら、定期パイプラインを回す必要はありません。
期待される結果: 毎日または毎週、新規登録された類似ドメインの一覧が、トリアージ可能な構造化メタデータ付きで得られます。
ステップ 2：怪しいリンクはデータセンタープロキシ経由で確認する
組織の誰かがリンクをクリックする前に、制御された経路で解析します。こうすれば、企業端末や社内ネットワークではなく、プロキシ IP が見えます。
やり方:
- すばやく確認するなら、urlscan.io（スキャンする国を選べる Web サンドボックス）や VirusTotal（多数のアンチウイルス製品とブロックリストで URL を検査）を使います。
- 社内スクリプトや大量分析なら、データセンタープロキシ経由でリクエストを流します。
curl -x http://proxy.example.com:8080 -I "https://suspicious.example"
- 実際のフィッシングページを確認する場合は、使い捨て VM またはブラウザサンドボックスを使います。認証情報は絶対に入力しません。リダイレクトの連鎖、ページタイトル、最終遷移先、フォーム送信、スクリプト、スクリーンショットを取得します。
- 本物の社内認証情報は絶対に送信しないでください。また、公開スキャンの扱いにも注意してください。サービスによっては、非公開設定にしていない URL が見えることがあります。
期待される結果: 企業の情報を露出させずに、リンク先・挙動・指標を安全に評価できます。
ステップ 3：地域分散プロキシで標的型フィッシングを見つける
フィッシングキットの中には、対象国や言語設定の訪問者にしか悪意ある内容を見せないものがあります。Cofense の記録 にある通り、位置情報フィルタリングはよく使われます。"対象外" の地域から来た訪問者には無害なページや 404 を見せ、ターゲットにだけ認証情報収集フォームを見せます。
やり方:
- 従業員、顧客、経理チームが実際にいる地域から怪しいリンクをテストします。会社が米国拠点で UK に支社があるなら、両方から確認します。
- 地域ごとに、最終 URL、スクリーンショット、ページタイトル、フォーム、HTTP レスポンスコードを比較します。
- QR コードやモバイル向けの誘導を調べるときは、ユーザーエージェントや言語設定も切り替えます。キットによってはそこでもフィルタリングします。
- ある場所では無害、別の場所ではログインフォームが出る URL はエスカレーション対象です。強いフィッシング兆候です。
期待される結果: 単一拠点のスキャンでは見えない、地域限定キャンペーンを発見できます。
ステップ 4：自社ドメインにリバースプロキシまたは WAF を導入する
ここからは外向き検知ではなく、内向き防御です。リバースプロキシと WAF は、自社 Web 資産の前面に立ち、サーバーに届く前にトラフィックを検査します。
やり方:
- ドメインの DNS をリバースプロキシ事業者へ向けます。Cloudflare は、中小企業にとって最も始めやすい選択肢です。DNS、CDN、WAF、ルール設定を一つの画面で管理できます。AWS で運用しているなら、CloudFront、ALB、API Gateway を使っている場合に AWS WAF がよく合います。
- マネージドルールを有効化します。既知の悪性 IP をブロックし、ボットトラフィックをふるい、クレデンシャルスタッフィングのパターンを検知します。
- ログイン、パスワード再設定、問い合わせフォームにレート制限を設定します。
- リスクの高いエンドポイントにはボット対策やチャレンジルールを追加します。
- WAF イベントは毎週確認します。放置しないことが大切です。
期待される結果: 悪意あるトラフィックがサーバーに届く前に止まります。ログインページへのクレデンシャルスタッフィングもブロックまたはチャレンジされます。
ステップ 5：監視を自動化し、定期運用にする
フィッシング対策は一度やって終わりではありません。新しいドメイン、キット、インフラが毎日出てくるので、監視にも定期運用が必要です。
- 毎日: CT による類似ドメインスキャンと怪しいドメインのキュー確認
- 毎日または毎時（高リスクブランドの場合）: 新規発見ドメインの URL サンドボックス確認
- 毎週: DMARC 集計レポートとなりすましパターンのレビュー
- 毎週: クレデンシャルスタッフィングやボット急増に対する WAF イベント確認
- 毎月: フィッシング耐性 MFA の展開進捗確認
- 四半期ごと: 経理と人事のワークフローを、現実的な AiTM や BEC シナリオでテスト
Thunderbit との連携: Thunderbit の定期スクレイピングや CLI/API ワークフローは、非技術系の運用チームにとって継続監視の助けになります。最適な使い方は「Thunderbit だけでフィッシングを防ぐ」ことではなく、「カスタムスクレイパーをゼロから作らずに、怪しいページやドメイン監視ソースから構造化シグナルを収集すること」です。結果は Google Sheets や Airtable に流してチームで可視化したり、簡単な連携で Slack に送ったりできます。
期待される結果: 週単位ではなく、数時間以内に新たな脅威を見つけられる継続監視ループができます。
プロキシでは防げないもの：DMARC、SPF、DKIM でメールを守る
プロキシ事業者はあまり強調しませんが、プロキシは防御の一層にすぎません。プロキシ層を通らないメール型フィッシングには、別の対策が必要です。
多くのフィッシングは、なりすましメールアドレスで届きます。プロキシでは止められません。
SPF をハードフェイルで設定する
SPF（Sender Policy Framework）は、どの IP が自社ドメイン名でメール送信してよいかを示す DNS レコードです。~all のソフトフェイルではなく、-all のハードフェイルで設定し、許可されていない送信元を明確に拒否します。
よくある落とし穴は、CRM、マーケティングツール、トランザクションメール、ヘルプデスクなど、正規の送信サービスを全部入れ忘れることです。レコードを公開する前に、送信元を洗い出してください。
DKIM 署名を導入する
DKIM（DomainKeys Identified Mail）は、送信メールに暗号署名を付ける仕組みです。受信側は、通信途中で改ざんされていないことを確認できます。Google Workspace と Microsoft 365 の両方に、標準の設定ガイドがあります。所要時間はおよそ 15 分です。
DMARC を reject にする
DMARC（Domain-based Message Authentication, Reporting & Conformance）は、SPF または DKIM の検証に失敗したとき、受信側サーバーにどう処理させるかを指示します。多くの組織が見落とす重要ポイントは、p=none（監視のみ）から、正規メールの流れを確認した後に p=reject（拒否）へ移行することです。
多くの企業は DMARC をずっと p=none のままにしています。可視化はあるのに防御はない状態です。防犯カメラを付けたのに、ドアの鍵は閉めていないようなものです。
類似ドメインを防御目的で取得する
自社ブランドにありがちな綴り違いや類似ドメインを先回りして取得しておきます。これらの防御用ドメインにも DMARC の reject ポリシーを設定すれば、なりすましメールに悪用されるのを防げます。1 ドメインあたり年 10～15 ドルほどでできる、安価で効果の高い対策ですが、見落としている中小企業は少なくありません。
全体像：フィッシングに対する多層防御
フィッシングを止める単一のツールはありません。防御を成立させるのは、複数の層を組み合わせることです。実践用チェックリストは次の通りです。
外向き（脅威調査）:
- 怪しいリンクのプロキシベース URL スキャン
- CT ログと一括抽出によるドメイン監視
- 地域分散テストによる標的型キャンペーンの検出
内向き（自社資産の保護）:
- 自社 Web ドメイン向けのリバースプロキシ / WAF
- メール認証用の DMARC / SPF / DKIM
- 類似ドメインの防御的取得
認証（アカウント保護）:
- フィッシング耐性 MFA としての FIDO2 / パスキー
- Conditional Access ポリシー（準拠端末、リスクベース検査）
- セッショントークンの監視と失効手順
人（最後の安全網）:
- AiTM 誘導、QR コード、BEC シナリオに特化した教育
- 申告しやすい文化――怪しいメッセージを報告しやすく、報告を罰しない
- 経理と人事の業務を、現実的なフィッシングシナリオで定期テストする
この考え方は、NIST Cybersecurity Framework のディフェンス・イン・デプス原則と一致します。つまり、独立した複数の層を重ね、1 つの層が破られても全体が崩れないようにするということです。
怪しい URL の調査、脅威データの抽出、大規模なドメイン監視が必要なチームにとって、Thunderbit の AI ウェブスクレイパー はワークフローを大幅に加速できます。非技術者には Chrome 拡張、技術チームには API / CLI が使えます。Thunderbit 自体はセキュリティ製品ではありませんが、アナリストのツールキットに入れる価値は十分あります。ノーコードでのウェブスクレイピング や、当ブログの AI ウェブスクレイピング 記事も参考になります。
AI ウェブスクレイピングで脅威監視を強化 Get Started Free
FAQ
攻撃者はプロキシを使ってどのようにフィッシング攻撃を行うのですか？
攻撃者は住宅系プロキシやローテーション型プロキシを使って本当の IP を隠し、信頼されている住所から発信しているように見せ、IP ベースの不正検知を回避し、さらに AiTM のリバースプロキシを使って、被害者が MFA を完了した後でも認証済みセッションを奪います。2026 年 1 月の IPIDEA 無力化では、1 つの住宅系プロキシネットワークを 550 以上の脅威グループが利用していたことが示されました。
リバースプロキシは、どのようにフィッシングや Web サイト侵害を防ぐのですか？
リバースプロキシは Web サーバーの前面に配置され、インフラに届く前の受信トラフィックを検査します。既知の悪性 IP をブロックし、ボットをふるい落とし、ログイン試行にレート制限をかけ、クレデンシャルスタッフィングやフィッシング関連の挙動を検知します。ただし、従業員が外向きのフィッシングリンクをクリックするのを直接止めることはできません。
プロキシだけでフィッシングを完全に防げますか？
いいえ。プロキシは重要な一層ではありますが、メール経由のフィッシングには DMARC / SPF / DKIM が必要で、AiTM によるセッション乗っ取りには FIDO2 / パスキーのようなフィッシング耐性 MFA が必要です。プロキシ、メール認証、フィッシング耐性のある認証情報、従業員教育を組み合わせた多層防御が不可欠です。
AiTM フィッシングとは何ですか？ なぜ MFA では止められないのですか？
AiTM（Adversary-in-the-Middle）フィッシングは、被害者と本物のログインページの間にリバースプロキシを置き、MFA 完了後のセッショントークンを盗みます。従来型 MFA では、攻撃者が盗むのはパスワードではなく認証済みセッションなので防げません。FIDO2 / パスキーは、暗号学的チャレンジが正規ドメインに結びついており、攻撃者のプロキシ経由では再利用できないため、この攻撃に強いです。
フィッシング検知に最適なプロキシの種類はどれですか？
大量の URL スキャンにはデータセンタープロキシが最適です（速くて安い）。地域別のテストには住宅系プロキシが最適です（現実的ですが高価なので、提供元の倫理的なソースを確認しましょう）。自社サイトの防御にはリバースプロキシ / WAF が最適です。最強の方法は、何を検知・保護したいかに応じてこれらを組み合わせることです。
脅威監視と AI スクレイピングに Thunderbit を試す Get Started Free
さらに詳しく
