【目次】

  1. はじめに
  2. 文字列一致条件（String matching）
  3. 正規表現一致条件（Regex matching）
  4. 活用例（誤検知対応）
  5. 除外ルールの作成例
  6. おわりに

■ はじめに

第3回は String and regex matching について機能と活用例を紹介します。

まだ第1回, 第2回の AWS WAF の仕組みに関するブログをご覧になっていない方は、そちらをご一読いただいた後に本ブログを読んでいただけますと、より理解していただけます。
 
第1回：AWS WAF 「基本構造編」
第2回：AWS WAF 「Condition と Filter の関係性」
第3回：AWS WAF 「String and regex matching の仕組みと活用例」（本記事）
 
本章では、AWS WAF をさらに深く理解するために欠かせないString and regex matchingの仕組みに焦点を当ててご紹介していきます。
Condition である String matching に検知させる文字列を Filter で登録して使用します。同様に Regex matching も Condition で Filter を正規表現で登録して使用します。
 

■ 文字列一致条件（String matching）

含まれている文字列に基づいてリクエストを許可または拒否する条件で様々な攻撃に対応させることが出来ます。完全一致、先頭一致、末尾一致を指定することで対象のアクセスのみ限定することが出来ます。注意点は最大長が５０バイトなので表現できる文字には制限があります。特定の脆弱性の攻撃パターンが分かる場合はマッチさせることで対応も可能です。
 

■ 正規表現一致条件（Regex matching）

リクエストに含まれる正規表現パターンと一致する文字列に基づいてリクエストを許可または拒否する条件で文字列一致よりも柔軟な指定が可能です。最大長は７０バイトとなります。通常の Condition と Filter の関係と違いは Regex pattern set という正規表現をまとめる Filter があることです。

Regex match condition を作成する際に、理解しておきたい構造を下記に図示しました。

<用語>
Regex match condition：Regex pattern set が適用された Condition のこと
Regex pattern set：Regex pattern strings をまとめたパッケージのようなもの
Regex pattern string：Regex pattern set の実態。実際にどのような攻撃を検知するかの文字列

< Regex match condition 作成時の手順>
  1. String and regex matching から Regex match を選択
  2. Filterの設定にて Regex pattern set (正規表現のパターンセット)を作成
  3. 作成した Filter を Condition に適用
  4. Condition の作成
  5. Regex match condition の完成

手順2にて作成した Regex pattern set は他の Regex match condition を作成する際に再利用することが可能です。
ただ、Regex match condition や Regex pattern set の作成には制限事項があるので注意してください。

<制限事項>
  ・ Regex match conditionはAWS 1アカウントで最大で10個まで
  ・ Regex pattern setはAWS 1アカウントで最大で5個まで
  ・ Regex pattern stringは1Regex patternsetで最大で10個まで

まとめると正規表現一致の Condition を作成する為には、正規表現を記載した Filter 郡を Regex pattern set に登録する必要がある。その Regex pattern set を Condition に紐づけて完成します。

正規表現はほとんどの標準 Perl 互換正規表現 (PCRE) をサポートしています。
公式情報は以下を参照してください。
正規表現一致条件の使用
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/web-acl-regex-conditions.html
 

■ 活用例（誤検知対応）

・誤検知が発生したら

WAF を運用していく上での課題の一つに誤検知が発生した際にどうするかという問題があります。対策の考え方は大きく二つに分かれ、アプリケーション側に問題がある場合はアプリケーションの修正を実施する。WAFでの検知を無効化する。それぞれ対応の良し悪しはあると思いますが、除外することでセキュリティに問題がないことを確認した上でこれから説明する除外方法を活用してください。

・暫定対応

誤検知が発生した際は緊急での対応が求められるケースがあり、緊急時は暫定対応を行い、アプリケーションが正常利用できることを優先させます。暫定での対応は対象ルールのみCOUNTモードへ変更することやホワイトリストの登録で回避してください。

・本対応

本対応は主に下記の4つの対応となります。
順番に検討していきましょう。

１．恒久的なホワイトリストへの登録
CMS等への管理者作業で誤検知が発生してしまうケースがあります。ルールに問題があるわけではなく、信頼できる接続元として判断できる場合はホワイトリストに該当IPアドレスを登録しましょう。

２．ルールの見直し
文字列一致条件や正規表現一致条件の場合、ルール自体の書き換えを検討しましょう。

３．除外一致条件の作成
システムの作りにより、どうしても特定のURIでのアクセスで誤検知が発生してしまうような場合はURI部分での一致条件（ /test/import/test のimportを含む等）を作成して回避することが可能です。他にもヘッダ内の情報で発生条件が絞れるようであれば登録は可能です。

４．COUNTモードでの運用
誤検知が発生するパスが絞りきれないケースやルール数の個数制限により除外条件を作成できない場合はCOUNTモードに変更しての運用を検討しましょう。即効性はないものの後で検証可能な状況にしておくことで運用していきます。

ケースバイケースでシステムによるところやセキュリティポリシーにもよるため、会社内での総合的な判断によって選択してください。
 

■ 除外ルールの作成例

除外ルールの実現方式を以下の２パターンで説明します。

１．Conditionでの除外

これまでに何度か例としてあげたパスでの除外を見てみましょう。Condition に除外する条件を“does not match(一致しない)”で登録します。Condition は AND 条件で評価されるため、Rule 内の Condition の全てが満たされることが真となる条件なるので、検知させたい条件は元々のルールに加えて除外したいパス以外ということになるためです。

具体的な例で言うと、既存のクロスサイトスクリプティングのボディ内での検知で誤検知が発生していたとします。Webサイトは WordPress を使用していて、検知は「/*/wp-admin/*」という特定のパスで発生している特徴がありました。そのような場合には「/wp-admin/」が含まれていた際に除外する条件を作成しましょう。
追加で設定する除外条件は「/wp-admin/」が含まれるパスに一致しない場合となります。

ルールの作成方法については過去のブログ記事をご参照ください。
・AWS WAF で URI に特定の文字列が含まれるリクエストをブロックする
https://www.wafcharm.com/jp/blog/block-specific-string-in-uri-jp/

同様の考え方で特定のIPアドレスの場合もIP一致条件で“does not match(一致しない)”で登録することで対応できます。

検知する条件を作成するというイメージで考えるとその条件にマッチしない条件を追加するという動きが理解ができるかと思います。

２．Ruleの順番での除外

第2回の「運用を想定した AWS WAF ルールサンプル」でホワイトリストルールを作成しました。特定のIPに一致した際は後続のルールを評価しない目的です。条件に一致した際に Allow で抜けるルールを作ると後続のチェックはされないことになります。

上記の挙動を使用すれば除外専用のルールを作り、SQLインジェクションはチェックするが後続にパスでマッチする Allow 条件を作り、その後続のクロスサイトスクリプティングでは評価しないといったことも可能です。

３．除外パターン例

よく使用する除外パターンを以下にまとめます。

・特定のパスで始まる
　Part of the request to filter on：URI
　Match type：Starts with
　Value to match：特定のパス

・特定のパスを含む
　Part of the request to filter on：URI
　Match type：Contains
　Value to match：特定のパス

・特定の拡張子へのアクセス
　Part of the request to filter on：URI
　Match type：Ends with
　Value to match：特定の拡張子

・特定のIPアドレスからのアクセス
　IP addresses：特定のIP

・ユーザー識別子がヘッダ情報に含まれるのであれば、特定のユーザー識別子からのアクセス
　Part of the request to filter on：特定のヘッダ
　Match type：Exactly matches
　Value to match：ユーザー識別子

 

■ おわりに

AWS WAF の仕組みを理解していただけましたでしょうか。
連載内容をお読みいただければ AWS WAF を使いこなせるはずです。
安心安全なWEBアプリケーションの運用を目指しましょう。