BIG-IP ASMについて② DoS Protectionの概要
1.DoS対策の概要
※本記事はv13.1.1.4を参考に作成されています。
BIG-IP ASMではクライアント側のトランザクションレート（TPS-based）またはサーバー側の遅延（latency-based）の計算に基づいて、通信がDoS攻撃であると判断します。 本設定ではシステムでしきい値を設定することが可能です。
ASMでは以下の異なるDoS Protectionの設定が可能です。
2.DoS Protectionの説明
2.1.Proactive Bot Defense
2.1.1.概要
botからの自動化された攻撃からアプリケーションを予防的に保護することができます。本防御方法はProactive Bot Defenseと呼ばれており、以下の攻撃に対して有効です。
- レイヤ7 DoS攻撃
- Webスクレイピング
- ブルートフォース攻撃
ASMのセキュリティポリシーで利用可能なWebスクレイピング、ブルートフォース保護に加えて、Proactive Bot Defenseを使用可能です。Proactive Bot DefenseはDoSプロファイルを介して実行されるので、セキュリティポリシーを作成しなくても使用可能です。
Proactive bot defenseが有効となっているASM経由でクライアントがWebサイトにアクセスすると、ASMがJavaScriptチャレンジをクライアントに対して送信します。大抵のブラウザはJavaScriptが有効とされているため、botではないクライアントは問題ないですが、botなどはJavaScriptを処理できないためレスポンスを返しません。そのため、この機能を使用する場合はクライアントがJavaScriptが有効であるブラウザを使用することが必要です。
クライアントがJavaScriptチャレンジを正常に処理し、有効なCookieを使用して要求を再送信するとシステムはサーバに到達できるようになります。JavaScriptチャレンジに対して応答しないとリクエストは未回答のまま残り、サーバに送信されません。CookieなしでHTML以外のURLに送信された要求はドロップされて、botとみなされます。
システムがJavaScriptチャレンジを検証しないようにURLリストを設定することも可能です。この設定でWebサイトへのアクセスが短縮されます。
2.1.2.Proactive Bot DefenseとCORS
Cross-Origin Resource Sharing（CORS）は、Webサイトが他のドメインサイトのリソースへアクセスを許可できる方法です。Proactive Bot Defenseは正常な通信でもCORS要求をブロックします。ブラウザは通常クロスドメインリクエストが、セッションライディングなどを防ぐためにクッキーを含まないため、ブロックされます。
したがって、Proactive Bot Defenseを有効にしてWebサイトでCORSを使用している場合は、CORS URLをProactive Bot URLホワイトリストに追加することが推奨されています。
一般的なクロスドメインリクエストは、埋め込み画像、スタイルシート（CSS）、JavaScriptなどの他のドメインのリソースを参照する場合です。 Proactive Bot Defenseはクロスドメインリクエスト設定でリソースを許可する特定のドメインを設定できます。
2.2.TPS-based DoS Protection
TPSによりDoSを検知する場合は以下の値が計算されます。
■Transaction Rate Detection Interval
■Transaction Rate History Interval
- 1秒あたりのリクエストの長期平均は過去一時間で計算され、10秒ごとにアップデートされる。
上記の設定された値と以下の計算により、攻撃と検知されます。
Transaction Rate History Intervalに対するTransaction Rate Detection Intervalの比率が、「TPS increased by」設定で定義されたパーセンテージよりも大きい場合、ASMは攻撃を受けていると判断、もしくはURLやIPアドレス、位置情報を疑います。もし、Transaction Rate Detection Intervalが「TPS reached」設定よりも大きい場合、再度それぞれのURLやIPアドレス、位置情報が疑わしいか攻撃を受けています。
TPSベースでDoSの防御を行おうとすると、誤検知を行う可能性があります。例えば新製品が発表された時など、Webサイトは多くのユーザのアクセスがあり、この通信をDoSとして誤検知する可能性があります。
ただし、TPSベースの方がストレスベースの防御よりも早く検出が可能であるため、Webシステムの最大負荷状態を理解して設定する必要があります。
2.3.behavioral & stress-based DDoS protection
2.3.1.Stress-based DoS protection
ストレスベースの検出では、遅延時間、少なくとも1つの疑わしいIPアドレス、URL、動作が重いURL、サイト全体のエントリ、または位置情報が必要になります。
平均遅延時間は仮想サーバーとDoSプロファイルごとに測定されます。 1つの仮想サーバーに複数のDoSプロファイルを設定した場合、各DoSプロファイルは仮想サーバーで独自の統計を持ちます。
ストレスベースのDoS保護には、Behavioral DoS protectionも含まれます。有効にすると、システムはトラフィックの動作を調べて、DoS攻撃を自動的に検出します。Behavioral DoS protectionは、問題のあるトラフィックを確認し、軽減します。
DoS攻撃ではサービス/応答時間が遅いため、ストレスベースの保護はTPSベースの保護よりも誤検知が起こりにくくなります。ただし大幅な待ち時間の増加が検出されたら、それ以上の対処を行うかどうかを判断することが重要です。1秒あたりのリクエスト数の増加を調べて、これらの数を過去の統計情報と比較することで、不審か通常かを特定できます。
2.3.2.Behavioral DoS protection
Behavioral DoS Protection(BADoS)は、機械学習とデータ分析を使用してトラフィックの動作を分析することにより、DDoS攻撃に対する自動保護を提供します。他のDoS Protectionと連携して、Behavioral DoSはクライアントとサーバー間のトラフィックを分析し、レイヤ7（HTTP）とレイヤ3およびレイヤ4のベースライントラフィック/フロープロファイルを自動的に算出します。
例えば、botからのDDoS攻撃を受けた場合、サーバーの処理速度が低下したりクラッシュする可能性があります。このような場合においてBehavioral DoSは、サーバーが正常な処理を行えるようにトラフィックをわざと遅く（スローダウン）することによって攻撃を軽減します。
Behavioral DoSは、リアルタイムで相関関係を確認し、サーバーの正常性と負荷を継続的に監視します。異常は監視され、システムは必要に応じて緩和（スローダウンまたはブロック）を行います。
以下がBehavioral DoSの概要です。
- 通常のトラフィックの振る舞いを学習
- サーバーの状態に基づいて攻撃を検出
- 異常な振る舞いを検知
- 疑わしいクライアントを遅くすることで攻撃の軽減
- 学習し動作改善
システムはトラフィックデータを監視し変化する状況に適応するため、しきい値の設定は必要ありません。学習のみから予防的DoS保護まで、緩和レベルを設定します。システムはレイヤ7 DoS攻撃を迅速に検出し、問題のあるトラフィックを特定し、攻撃を軽減することができます。
Behavioral DoSを有効にしたDoSプロファイルを使用すると、1つまたは最大2つのVirtual Serverの保護が可能です。
3.DoS緩和手法
TPS-basedもしくはStress-based Protectionを設定している場合に、システムがDoS攻撃を緩和する方法を指定可能です。
- JavaScript challenges (Client-Side Integrity Defenseとも呼ばれます)
- CAPTCHA challenges
- 要求のブロック (レート制限もしくは全ブロックなど)
クライアントが正規のブラウザを使用しているかどうかを分析するためにJavaScriptチャレンジを使用することができます。クライアントがチャレンジに応じてJavaScriptを実行した場合、システムは意図的に対話を遅くします。 Client Side Integrity Defenseによる緩和策は、Operation Modeがブロッキングに設定されている場合にのみ有効になります。
同じ疑わしい基準に基づいて、システムはCAPTCHA（文字認識）チャレンジを発行して、クライアントが人間なのか違法なスクリプトなのかを判断することもできます。 DoS保護をどの程度厳密に適用するかに応じて、サーバーへの通過を許可する要求の数を制限したり、疑わしいと思われる要求をブロックしたりできます。
DoSプロファイルで要求ブロックを使用して、システムが要求をブロックするときの条件を指定することもできます。 TPSベースまたはストレスベースの検出の動作モードが[ブロック]に設定されている場合、システムはDoS攻撃中にのみ要求をブロックします。リクエストブロッキングを使用して、疑わしいIPアドレス、疑わしい国、または攻撃を受けている疑いのあるURLからのすべてのリクエストをレート制限またはブロックできます。サイト全体のレート制限は、攻撃を受けている疑いのあるWebサイトへのリクエストもブロックします。すべてのリクエストをブロックすると、システムはホワイトリストに登録されているものを除き、疑わしいIPアドレスと位置情報をブロックします。レート制限を使用している場合、DoSプロファイルに設定されているしきい値検出基準に応じて、システムによって一部の要求がブロックされます。
選択した軽減方法は、画面に表示されている順序で使用されます。以前の方法で攻撃を阻止できなかった場合にのみ、システムは必要に応じて方法を実行します。
3.1.geolocation mitigation
疑わしいトラフィックを送信している国からのトラフィックを検出することで、位置情報に基づくDoS攻撃を軽減できます。これは、TPS-baseおよびStress-baseの異常に対するDoSプロファイルの緩和方法の一部です。この方法は、以下のように異常な活動から保護するのに役立ちます。
- Geolocation-based Client Side integrity：トラフィックがDoSプロファイルで設定されたしきい値を超えた場合、クライアントが所属する国を疑わしいと判断し、被疑国に所属するクライアントに対してJavaScriptのチャレンジを送信します。
- Geolocation-based CAPTCHA challenge：トラフィックがDoSプロファイルで設定されたしきい値を超えた場合、クライアントが所属する国を疑わしいと判断し、被疑国に所属するクライアントに対してCAPTCHAチャレンジを発行します。
- Geolocation-based request blocking：被疑国に所属するクライアントからのリクエストの全部または一部をブロックします。
国をホワイトリストとブラックリストに追加できます。ブラックリストに登録された国からの攻撃が検知されると通信がブロックされます。
3.2.heavy URL protection
heavy URLは、リクエストごとに大量のサーバーリソースを消費する可能性があるURLです。DoS攻撃の対象となることで、高レイテンシに達する可能性があります。
通常、大規模なサイトでは複雑なデータベースクエリを伴います。例えば、過去の統計情報の取得などです。長期間の統計情報の取得を行うと大量のデータ検索が必要となるため、多くのリソースを要します。
ASMでは、DoSプロファイルを使用してheavy URLの保護が可能です。heavy URLを自動的に検出するための待ち時間しきい値を指定できます。heavy URLとなり得るURLが判明しているのであれば、システムがそれらを監視するように手動で追加したり、無視して監視しないように設定することができます。
システムは各URLとサイト全体の24時間のテールレイテンシを測定します。 URLの平均テールレイテンシが24時間のサイトレイテンシの2倍を超える場合、そのURLは重いと見なされます。
3.3.cross-domain requests
DoSプロファイルでProactive Bot Defenseを使用すると、どのクロスドメイン要求が正当であるかを指定できます。クロスドメインリクエストとは、リクエストを行っているリソースのドメインとは異なるドメインからのリソースに対するHTTPリクエストです。
アプリケーションが複数のクロスドメインリソースにアクセスし、それらのドメインのリストがある場合は、それらのドメインへのクロスドメイン要求を検証できます。
たとえば、Webサイトではsite1.com（メインサイト）とsite2.com（リソースが格納されている場所）の2つのドメインを使用しています。これをDoSプロファイルで設定するには、Proactive Bot Defenseを有効にし、「Cross-Domain Requests」設定で「Allowed configured domains」オプションを選択して、関連サイトドメインのリストで両方のWebサイトを指定します。ブラウザがsite1.comにリクエストを送信すると、site1.comとsite2.comの両方に対して同時に別々のクッキーが取得され、site1.comからsite2.comへのクロスドメインリクエストが許可されます。
site1.comのみが関連サイトドメインとして設定されている場合、ブラウザがsite1.comにリクエストを送信すると、site1.comのcookieのみが取得されます。ブラウザがsite2.comから画像を取得するためにクロスドメインリクエストを行うと、ブラウザはcookieを取得し、すでに有効なsite1.com cookieを持っている場合にのみ許可されます。
3.4.site-wide DoS mitigation
複数のURLを攻撃する大規模ボットネットを使用した攻撃など、高度に分散されたDoS攻撃を軽減するために、DoSプロファイルでサイト全体の軽減策を使用するタイミングを指定できます。 TPSベースまたはストレスベースのDoS保護に対してサイト全体の緩和策を設定できます。この場合、特定のURLやIPアドレスではなく、サイト全体が疑わしいと見なされる可能性があります。サイト全体で大量のトラフィックが発生しているが、問題を特定して処理できないとシステムが判断した場合、サイト全体の緩和策が実施されます。
システムが正当な要求を落とす可能性があるため、システムはサイト全体の緩和方法を最後の手段としてのみ実装します。ただし、攻撃を受けている場合でも、Webサイトの可用性は少なくとも部分的に維持されます。システムがサイト全体の緩和策を適用するとき、それは他のすべてのアクティブな検出方法が攻撃を阻止することができなかったからです。
設定されたしきい値を超えた場合、サイト全体が疑わしいと見なされます。同時に特定のIPアドレスとURLも疑わしいと判断される可能性があります。軽減は、最大期間が経過するか、サイト全体が攻撃されなくなったと判断されるまで続きます。
3.5.CAPTCHA challenges in DoS detection
CAPTCHA（Completely Automated Public Turing test to tell Computers and Humans Apart）Challengeでは、クライアントがWebサイトまたはアプリケーションにアクセスする前に識別できる文字を表示します。 クライアントが文字を正しく識別できるかどうかによって、クライアントが人間であるのか、それとも違法なスクリプトであるのかが決まります。 TPS-baseのDoS検出、Stress-baseのDoS検出、またはProactive Bot Defenseの一部として、CAPTCHAチャレンジを緩和方法として設定できます。
システムは標準のCAPTCHAレスポンスをクライアントに提供します。 必要に応じてレスポンスをカスタマイズできます。
3.6.DoS protection and HTTP caching
HTTPキャッシングにより、頻繁に要求されるWebオブジェクト（または静的コンテンツ）をメモリに保存して、帯域幅を節約し、Webサーバーのトラフィック負荷を減らすことができます。 Web高速化プロファイルには、キャッシュを構成するための設定があります。
DoS ProtectionとともにHTTPキャッシングを使用している場合は、キャッシュされたコンテンツに対するDoS保護がどのように機能するかを理解する必要があります。 キャッシュされたコンテンツを提供するURLは、パーセンテージで増加した相対TPSを超えると、DoS攻撃と見なされます。 静的URLまたはキャッシュ可能URLへの要求は、レート制限によって常に軽減されます。
4.まとめ
- TPS-base、Stress-base、Behaviral-base、Proactive Bot Defenseなどを使用してDoSを防御
- JavaScript challenges、CAPTCHA challenges、スローダウン、ブロックなどでDoSを緩和
BIG-IP ASMについて① ASM概要 - インフラエンジニア勉強雑記
BIG-IP ASMについて② DoS Protectionの概要 - インフラエンジニア勉強雑記
