WAFでボットとLayer 7 DDoSを防ぐ ― ちょうど良いレート制限の設定方法
Layer 7 DDoSは正当なリクエストを装うため、ネットワーク型ファイアウォールでは検知できません。WAFのレート制限の設定方法を解説します。
WAFでボットとLayer 7 DDoSを防ぐ ― ちょうど良いレート制限の設定方法
DDoSと聞いて多くの人が思い浮かべるのは、ネットワーク全体をダウンさせるほどのトラフィック洪水です。もっと静かで検知しづらいタイプの攻撃があります ― Layer 7 DDoS は、見た目は完全に正当なHTTPリクエストを送信します。実際のユーザーが閲覧しているのとまったく同じように見えますが、システムが処理できる限度をはるかに超える頻度で送られるか、大量のアカウントに対してパスワードを試すことを目的としています。正常なトラフィックを模倣しているため、ネットワークレベルのファイアウォールは何の異常も検知できません。
WAFの レート制限 はこの問題への回答です ― 単一IPが一定時間内に送れるリクエスト数の上限を設定します。ただし設定を誤ると、実際のユーザーも一緒にブロックしてしまいます。この記事では、正しく調整する方法を解説します。
なぜLayer 7 DDoSは検知しづらいのか
ネットワーク層のDDoS（L3/L4）は帯域そのものを大量トラフィックで埋め尽くすため、トラフィック量自体が異常なので発見しやすいものです。Layer 7 DDoSは正常に見えるHTTPリクエストを送りますが、通常よりはるかに高い頻度で送るか、検索やログインページのようにリクエストごとにデータベースを叩くリソース消費の大きいエンドポイントを狙い撃ちします ― 全体のトラフィック量は異常に見えないまま、サーバーに負荷をかけます。
よく見られるパターン：
- クレデンシャルスタッフィング ― 他所から漏えいしたメール／パスワードの組み合わせでログインを繰り返し試行
- スクレイピング ― ボットが商品価格やコンテンツを大量かつ繰り返し取得
- アプリケーション層のフラッド ― 通常より多くのCPU・データベース負荷がかかる特定のエンドポイントを狙ったリクエスト
3つのレート制限層が連携する仕組み
zcrWAFのデモのRate Limiting画面に設定されている値：
1) Visit Limit ― 単一IPからの一定時間内の総リクエスト数を制限します。デモの設定値は、Trigger Thresholdが1,200リクエスト、Block Durationが300秒で、しきい値を超えたIPはその時間ブロックされます。リクエストを数える時間ウィンドウは、Show Advanced Optionsの内側にあります。スクレイピングや一般的な高頻度トラフィック対策に使います。
2) Attack Limit ― システムが既に攻撃パターンと判定したリクエストのみを制限します。デモの設定値は、Trigger Thresholdが20リクエスト、Block Durationが900秒（15分）です ― このトラフィックは既に不審と確認されているため、Visit Limitよりもはるかに厳しく設定されています。
3) Error Limit ― 単一IPが受け取ったエラーレスポンス（401、403、404）の回数を制限します。デモの設定値は、Trigger Thresholdが80、Block Durationが600秒（10分）です ― クレデンシャルスタッフィングやエンドポイントスキャンの検知に使います。短時間にエラーを繰り返し受け取るIPは、単純に入力を間違えた実際のユーザーであることはほとんどないためです。
3つは並行して機能します ― Visit Limitは一般的な高負荷トラフィックを、Attack Limitは既に確認済みの攻撃を、Error Limitは試行錯誤的な探りを捉えます。上の数値はデモ自身の設定であり、自社サイト向けの推奨値ではありません。
実際のユーザーをブロックせずに調整する方法
- 高めの閾値から始めて、後から絞り込む ― まず1〜2週間、実際のトラフィックパターンを観察し、いきなり数値を決め打ちするのではなく、実際のユーザーのベースラインより十分高い値に設定します
- エンドポイントごとに異なる閾値を設定する ― ログインページや検索ページは、クレデンシャルスタッフィングやスクレイピングの主な標的になるため、一般的な商品ページよりも厳しい閾値が必要です
- 境界線上のトラフィックは即ブロックせずCAPTCHAを使う ― 不審だが明確に悪意があるとは言い切れないトラフィックには、CAPTCHAチャレンジが実際のユーザーを即座に締め出すことなくボットを除外してくれます
- Error Limitは実際のログと突き合わせて確認する ― 実際のユーザーを頻繁にブロックしすぎている場合、それは純粋なセキュリティ問題というより、エラーを頻発させるUXの問題を示している可能性があります
PDPAとの関係
クレデンシャルスタッフィングが成功したということは、誰かが認証なしにユーザーアカウントにアクセスしたことを意味し、そのアカウントに紐づく個人データが露出する可能性があります。それが実際のデータ漏えいにつながれば、組織はPDPAに基づく報告義務を負います。適切に調整されたレート制限は、そもそもこうした事態が起きる確率を下げる層です。
zcrWAFがこの問題にどう対応するか
zcrWAFには上記の3つのレート制限層すべてがサイトごとに設定可能な形で搭載されており、不審だが明確に悪意があるとは言い切れないトラフィック向けのCAPTCHAチャレンジも備えています。同じプラットフォーム内でOWASP Top 10の検知とも連携します。
自社サイトが実際にどれだけのボットトラフィックやクレデンシャルスタッフィングを受けているか気になる場合は、zcrWAFのプランをご覧ください。
出典
- Cloudflare — What's an Application Layer DDoS Attack — Layer 7 DDoSが正常なトラフィックと見分けがつきにくく、ネットワーク全体ではなくログインページやAPIなど特定のエンドポイントを狙うことが多いという本文の説明を裏付ける
- OWASP — Credential Stuffing — 本文で使用しているクレデンシャルスタッフィングの定義と仕組みを裏付ける
- IAPP — Thailand's PDPC Clarifies Data Breach Notification Requirements — タイのPDPAにおいて、データ管理者が個人データ漏えいを報告する義務を負うことを裏付ける
お問い合わせ
運用中のWebサイトが実際にどれだけのボットトラフィックや異常なリクエストを受けているか、気になりませんか。お気軽にご相談ください。無料でご相談いただけます。