サービス拒否ポリシー

サービス拒否 (DoS) ポリシーは、API への正当なネットワークトラフィックの妨げとなるネットワークへのフラッド攻撃を防ぎます。たとえば、悪意のあるクライアントは、リソースと帯域幅を消費するように設計された大きなペイロードをネットワークに送信する可能性があります。

DoS ポリシーを作成する場合、期間、および設定した​エラー種別​が発生したときに実行するアクションを設定します。同じ IP アドレスから設定済みのしきい値を超えるエラー数が発生した場合、ポリシーは (TLS 接続を試みずに) 自動的に接続を切断するか、直ちに接続を切断して ​503​ エラーを返します。

DoS ポリシーは、次の 3 つの方法で要求のソースを判断します。

  • TCP メッセージ - ソース IP アドレス

  • ソース IP アドレスのヘッダー項目

  • Proxy Protocol IP アドレス

要求のソースは IP アドレスに基づいているため、攻撃者が自分のソース IP アドレスを偽装した場合、DoS ポリシーで攻撃を防ぐことはできません。

エラー種別

DoS ポリシーを設定するときに、既存のセキュリティポリシーに対応するさまざまなエラー種別を設定できます。たとえば、​[Protocol Errors (プロトコルエラー)]​ は HTTP 制限ポリシー違反に対応します。 異なるエラー種別を設定する場合、ポリシー違反がアクションの DoS ポリシーに送信 (エスカレーション) されるしきい値を設定します。「​​ルール、しきい値、エスカレーション​」を参照してください。エラーの設定方法によって、設定済みのしきい値が満たされたときに実行されるアクションが決まります。

エラー 説明

Protocol Errors (プロトコルエラー)

クライアントが不正なプロトコルメッセージを送信した場合。

HTTP 制限ポリシー違反は ​[Protocol Errors (プロトコルエラー)]​ として DoS ポリシーにエスカレーションされます。

Routing Errors (ルーティングエラー)

クライアントがアプリケーションに正常に転送できないメッセージ要求を送信した場合。

API Manager の IP ブラックリスト/ホワイトリストまたは RAML 検証ポリシーへの違反は、​[Routing Errors (ルーティングエラー)]​ として DoS ポリシーにエスカレーションされます。

Authentication Errors (認証エラー)

認証または承認の失敗が発生した場合。
これには、SSL ハンドシェイク中にクライアントが不正な証明書を送信した場合、AAA ポリシーでの認証または承認の失敗、または WS-Security 検証ポリシーが WS-Security 署名の検証に失敗した場合が含まれます。

API Manager の LDAP、HTTP、OAuth、OpenAM、または Ping Federate 認証ポリシーへの違反は、​[Authentication Errors (認証エラー)]​ として DoS ポリシーにエスカレーションされます。
IP ホワイトリストポリシー違反も認証エラーとしてエスカレーションされます。

QoS Errors (QoS エラー)

サービス品質 (QoS) エラーが発生した場合。
たとえば、クライアントはパケットを破棄して TCP サービスを低下させ、TCP のパフォーマンスに悪影響を及ぼすことによって、多数の QoS エラーを強制的に発生させようとする可能性があります。

API Manager レベルでのレート制限、SLA ベース、または Ping Federate ポリシーへの違反は、​[QoS Errors (QoS エラー)]​ として DoS ポリシーにエスカレーションされます。

Content Errors (コンテンツエラー)

コンテンツエラーは、クライアントがスキーマに準拠しない破損データを送信したり、コンテンツ攻撃防止ポリシーに違反したりしたときに発生します。

API Manager レベルでの JSON または XML 脅威保護ポリシーへの違反は、​[Content Errors (コンテンツエラー)]​ として DoS にエスカレーションされます。

WAF Errors (WAF エラー)

WAF エラーに適用するアクション (指定期間の IP アドレスのブロックなど) を設定します。

応答または要求ルールセットへの違反は、​[WAF Errors (WAFエラー)]​ として DoS にエスカレーションされます。

ルール、しきい値、およびエスカレーション

DoS ポリシーの設定方法を理解するには、クライアントのメッセージが DoS ポリシーによって絞り込まれるタイミングと理由を理解する必要があります。
タイミング ​は設定した時間枠によって決まり、​ 理由 ​は DoS しきい値によって決まります。

DoS ポリシーでさまざまなエラーを設定するときに、時間枠を設定できます。期間は秒単位で測定され、エラーアラートの受信後、DoS 攻撃が行われていることを確認し、設定済みのアクションを攻撃者のメッセージに適用します。
次の DoS アクションを設定できます。

  • None (なし)​: ルールを作成しない場合、アクションは実行されない。

  • Limit its messages (そのメッセージを制限)​: このルールは、(指定時間枠の残りまたは無期限で) 設定した時間枠の終了まで、指定したクライアントのメッセージレートを制限。

  • Block all messages (すべてのメッセージをブロック)​: ポリシーは、(指定時間枠の残りまたは無期限で) 設定した時間枠の終了まで、すべてのクライアントのメッセージ要求を拒否。

指定期間が終了すると、ポリシーにはシェイプ期間またはブロック期間が適用されません。
各時間枠内で許容するエラーの数を設定できます。このエラーの数が DoS カウントになります。DoS エラーの種別ごとに最大 3 つの DoS 時間枠を設定できます。各時間枠内で、設定した DoS カウントが満たされるたびに、ポリシーはクライアントのメッセージ要求に対していずれかの DoS アクションを適用できます。
たとえば、60 秒の時間枠 (1 分の期間) を設定し、その時間枠内に 2 つのプロトコルエラーが発生した場合 (DoS カウントは「2」)、クライアントからのそれ以降のすべての要求が拒否される (永久にブロックするアクションを適用する) ポリシーを設定できます。

エラーごとに最大 3 つの異なるルールを設定できます。各ルールはエスカレーションレベルに対応します。​ルール A​ は最低のエスカレーションレベルで、​ルール C​ は最高のエスカレーションレベルです。
ルール A​ より高いエスカレーションレベルでルールを設定する場合、その前のルール (ルール Bの場合はルールA、ルール C の場合はルール B) の期間に基づいて、それらのルールの期間をセットアップできます。
たとえば、​ルール B​ を​ルール A​ の 2 つの期間となるように設定できます。つまり、​ルール A​ の期間が 60 秒の場合、​ルール B​ の期間は 120 秒になります。
さらに、ルールごとに異なる DoS カウントを設定し、しきい値の概念を適用できます。
各ルールには次の異なるしきい値があります。

  • ルール A​ の場合、しきい値は​ルール A​ 内で DoS アクションが適用されるときの DoS カウントの値です。

  • ルール B​ の場合、しきい値は​ルール B​ 内で DoS アクションが適用されるときの​ルール B​ DoS カウントの値です。
    ルール B​ DoS カウントは、その​ルール B​ 内で実行される​ルール A​ DoS アクションの数です。

  • ルール C​ の場合、しきい値は​ルール C​ 内で DoS アクションが適用されるときの​ルール C​ DoS カウントの値で、​ルール C​ DoS カウントはその​ルール C​ 内で実行される​ルール B​ DoS アクションの数でもあります。

これに基づき、DoS しきい値に違反したときに時間枠のエスカレーションが発生します。

エラーとしてのポリシー違反のエスカレーション

DoS ポリシーが設定されている場合、HTTP プロトコルエラー (悪意のあるプロトコル違反の試行)、IP ホワイトリスト、WAF、および HTTP 制限ポリシー違反が DoS にエスカレーションされます。API ゲートウェイによって提供される一部のポリシーも DoS にエスカレーションされます。違反とエラーのエスカレーションの具体的な対応付けは、次の表を参照してください。

違反 エスカレーション種別

Anypoint Security ポリシー

IP ホワイトリストポリシー

Authentication Error (認証エラー)

HTTP 制限ポリシー

Protocol Error (プロトコルエラー)

エンドポイントレベルでのエラー

エンドポイントでの HTTP プロトコルエラー

Protocol Errors (プロトコルエラー)

エンドポイントでの TLS ハンドシェイクエラー

Protocol Errors (プロトコルエラー)

転送不可能な API パスを使用する公開エンドポイントで受信した要求

Routing Errors (ルーティングエラー)

API ゲートウェイで提供されるポリシー

クライアント ID 適用

Authentication Error (認証エラー)

Mule OAuth 2.0 アクセストークン

Authentication Error (認証エラー)

OpenAM OAuth 2.0 トークン適用ポリシー

Authentication Error (認証エラー)

OpenID Connect OAuth 2.0 トークン適用

Authentication Error (認証エラー)

PingFederate OAuth 2.0 トークン適用

Authentication Error (認証エラー)

基本認証: シンプル

Authentication Error (認証エラー)

基本認証: LDAP

Authentication Error (認証エラー)

IP ブラックリスト

Content Error (コンテンツエラー)

IP ホワイトリスト

Content Error (コンテンツエラー)

JSON 脅威保護

Content Error (コンテンツエラー)

XML 脅威保護

Content Error (コンテンツエラー)

レート制限および調整 - SLA ベースのポリシーの概念

QoS Error (QoS エラー)

レート制限および調整

QoS Error (QoS エラー)

調整およびレート制限

QoS Error (QoS エラー)

DoS ポリシーを設定する

  1. [Anypoint Security]​ に移動し、​[Create Policy (ポリシーを作成)]​ をクリックして ​[Denial Of Service (サービス拒否)]​ を選択します。
    DoS ポリシーを適用するプロセスには 6 つの異なる画面があります。

    離れる前にすべての画面を保存しないと、その画面での変更内容が失われます。
  2. 左のナビゲーションバーで、​[General (一般)]​ をクリックします。

    1. [Name (名前)]​ 項目にポリシーの名前を追加します。

    2. [Rule A Time Period (ルール A の期間)]​ で、期間を秒単位でセットアップします。
      この期間は、各種別のエラーで設定したエラー数が発生した場合に、ポリシーが要求をブロックし始めるしきい値です。

    3. [Max Sources To Monitor (監視する最大ソース数)]​ 項目を使用して、追跡する IP アドレスの最大数をセットアップします。
      DoS ポリシーは最大 500,000 IP アドレスを追跡するように設定できます。

    4. [Reject Message Action (メッセージアクションを拒否)]​ ドロップダウンメニューを使用して、クライアント接続が切断されたときにポリシーが返す応答の種別を選択します。次の 2 つのオプションがあります。

      • Drop Silently (自動的に切断)​: ポリシーは接続を自動的に切断し、TLS ハンドシェイクを完全に回避する。ポリシーは、AWS ELB Proxy Protocol ヘッダーにソース IP アドレスがある TCP パケット、または TCP パケットから取得されたソース IP アドレスへの接続を回避します。ポリシーは攻撃者の要求を読み取らないため、これはクライアントの接続を終了するために最も効率的な方法です。

      • Send HTTP 503 (HTTP 503 を送信)​: ポリシーは接続を終了し、クライアントに ​503 (Service Unavailable)​ 応答を返します。これには TLS 接続が必要になり、多くのリソースを消費します。

        DoS ポリシーは次の条件を満たす場合、DoS アクションを適用する前に、HTTP メッセージ内のソース IP ヘッダー (「x-forwarded-for」や「forwarded」など) に接続して読み取る必要があります。

        • アプリケーションがロードバランサの背後にある。

        • ロードバランサが Proxy Protocol V1 または AWS NLB をサポートする AWS ELB ではない。

        これは、​[Reject Message Action (メッセージアクションを拒否)]​ で ​[Drop Silently (自動的に切断)]​ を指定しているかどうかに関わらず適用されます。

  3. これで、さまざまなエラー種別に対してアクションを実行するポリシーを設定できます。

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub