1. Home
2. Next-Gen WAF
3. ルール

ルールを作成する際には、WAF がアクションを実行するためにリクエストが満たすべき条件を定義します (例 : 一致するリクエストを許可もしくはブロックするなど)。

ルール条件について

ルール条件は、フィールド、演算子、値で構成されます。

フィールド

ルール条件は特定のフィールドに基づいています。

リクエストルールまたは高度なレート制限ルールを作成する際、ルール条件は次のリクエストフィールドに基づいて設定できます。

シグナル除外ルールを作成する際、同じリクエストフィールドと、除外対象となる特定のシグナル固有のフィールドに基づいてルール条件を設定できます。

演算子

ルールを作成する際、条件に一致したときのルールのロジックを指定するために使用されます。たとえば、等号演算子は特定の IP アドレスやパスを一致させようとする場合など、リクエストの値がルール条件の値と完全に一致するかどうかを確認するために使用されます。

ワイルドカード

Like (ワイルドカード) 演算子は glob 構文を使用し、0個以上のワイルドカード (*)、1文字のワイルドカード (?)、文字リスト ([abc])、文字範囲 ([a-c]、[0-9])、選択肢 ({cat,bat,[fr]at})、および除外 ([!abc]、[!0-9]) をサポートします。

リテラル *、?、[、もしくは ] 文字にマッチする必要がある場合、それらを \ 文字でエスケープします。例 : \*。

Like (ワイルドカード) 演算子では文字列の一致が条件となります。文字列の一部を照合する場合は、文字列の残りの部分も含めて正しく一致させるため、最初や最後に * ワイルドカードを含める必要がある場合があります。

Like (ワイルドカード) 演算子では正規表現はサポートされていません。正規表現を使用する場合は、Matches (正規表現) 演算子を使用する必要があります。

フィールド値の大文字小文字の区別

ヘッダー名を除き、ルールのすべてのフィールドは大文字と小文字を区別します。

たとえば、X-Custom-Header という名前のヘッダーを検索するルールを作成した場合、ヘッダー名は大文字小文字を区別しないため、X-Custom-Header や x-custom-header という名前のヘッダーを持つリクエストが一致します。ただし、Example-Value という値を検索するルールでは、ヘッダー値などの他のすべてのルールフィールドが大文字と小文字を区別するため、Example-Value とは一致し、example-value とは一致しません。

ヒント : ヘッダー名、POST パラメータ名、もしくはクエリパラメータ名と一致する正規表現パターン (regexp) を構築する際は、パターンをすべて小文字で記述するか、パターンに大文字と小文字を区別しない正規表現マッチングモードの接頭辞 (?i) を付加してください。

シミュレーターでルールロジックをテストする

ルールロジックのテストとデバッグを行うには、シミュレーター機能を使用してください。シミュレーターを使用すると、Next-Gen WAF の検知エンジンを通じてサンプルのリクエストとレスポンスを送信できます。構築されたサンプルに基づいて、検知エンジンは次の情報を含む出力を生成します。

• WAF がサンプルリクエストをブロックまたはログ記録を行うかどうか

• 返されるレスポンスコード

• WAF がリクエストに追加するシグナル

• 修正が発生するかどうか

制約事項

シミュレーターには次の制限があります。

• シミュレーターは、高度なレート制限ルール、偽装アクション、位置情報 (つまり、国コードを使用するルール) をサポートしていません。

• シミュレーターはリバースプロキシのデプロイメント実装を使用しています。エッジ WAF のデプロイ方法を使用する場合、実装とシミュレーターの間に不一致が生じることがあります。

• 処理終了時に残っているシグナルが情報提供用とみなされる場合、シミュレーターは、リクエストに追加されたシグナルを返しません。ただし、リクエストが明示的にブロックまたは許可されている場合はこの限りではありません。

シミュレーターを使用する

シミュレーターを使用するには、次の手順を実行します。

Path フィールド

Path フィールドに基づいてルール条件を設定する際は、次のベストプラクティスを念頭に置いてください。

• 常に先頭にスラッシュを使用してください。https://example.com/some-path のような URL の場合、使用する正しいパス構文は /some-path です。

• 絶対 URL の代わりに相対パスを使用してください。たとえば、Web サイトのログインページへの絶対 URL が https://example.com/login の場合、ログインシグナルを設定する際に入力する正しいパス構文は /login となります。

• パスで末尾の文字を使用する際にはご注意ください。パス構文では完全一致を使用するため、末尾の文字により一致なしと判断される場合があります。たとえばログインページへのパスが https://example.com/login/ である場合、

  • /login/ は一致を返します。

  • /login は一致を返しません。

Post Parameter フィールド

POST リクエストの JSON ボディを検査するルールを作成する際、POST パラメータ名には先頭に / を付ける必要があります。たとえば、JSON ペイロードが次の場合、

{
  "foo": "bar"
}

ルール内の POST パラメータの名前は /foo である必要があります。

POST パラメータ名の先頭に / を付けると、値を入れ子にしやすくなります。たとえば、ペイロードに /foo/bar を使用して、次のようにします。

{
  "foo": {
    "bar": ["value1", "value2"]
  }
}

Country フィールド

Country フィールドでは、特定の国に一致する条件を指定してトラフィックをブロックまたは許可できます。位置情報は、パスやドメインなどの他の条件と組み合わせることができます。

位置データの取得先

Digital Element のデータライセンスを取得し、エージェントを通じて配信しています。このデータは定期的に更新され、新しいエージェントのリリースに含まれるほか、ルールの更新と同様に動的に更新されます。

位置データの更新頻度

毎月 (通常は第2週目) 位置データを更新しエージェントをリリースします。エージェントのリリースと同時に、新しい位置データがクラウドタグにデプロイされ、最新の国情報が反映されます。これはマイナーなエージェントの増分になります。このデータもルールの更新と同様に動的に更新されます。これらのエージェントは更新された位置情報データをダウンロードしてキャッシュします。

エージェントが古い場合

エージェントが古い場合、その古い位置情報に基づいて IP がブロックまたは許可される可能性があります。あるいは、最新の位置データではブロックされていたはずのリクエストがコンソールに表示される場合があります。コンソールに表示される国には、利用可能な最新の位置データが反映されます。

動的な位置情報データ更新の仕組み

位置情報データは、更新があるたびにエージェントがダウンロードできるようにパッケージ化されます。このデータはエージェントマシンにローカルでキャッシュされます。キャッシュの場所は、shared-cache-dir ディレクトリの下にあり、デフォルトで {$TMPDIR|%TMP%|%TEMP%}/sigsci-agent.cache/ です。位置情報データは、ローカルに存在しない場合、もしくはデータが最新でない場合にのみ、ダウンロードされます。

この機能の動作条件は次のとおりです。

• このキャッシュディレクトリが置かれているファイルシステムは、次の条件を満たしている必要があります。

  • エージェントの実行者による書き込みが可能

  • 少なくとも 5MB の空き容量がある

  • キャッシュディレクトリの自動検知は通常正常に機能しますが、TEMP 領域が定義されていない一部のシステム (例 : $TMPDIR、%TMP%、または %TEMP% 環境変数が適切に設定されていない) では、shared-cache-dir の設定が必要になる場合があります。

• ネットワークは次の機能を備えている必要があります。

  • ベース download-url からダウンロード (通常のルール更新と同じベース URL)

  • タイムアウト制限 (現在60秒) 内にデータ (現在約 2MB) をダウンロード

動的な位置情報データをダウンロードできない場合、エージェントはエージェントに同梱されている位置情報データをデフォルトで使用します。

関連コンテンツ

• リクエストをルールに変換する

• Next-Gen WAF での API の使用