マネージドルール内のルールIDが異なるAWSアカウントでも共通か確認する

AWS WAFマネージドルール内のルールIDが、異なるAWSアカウントでも共通か確認しました。結果をお伝えすると、少なくとも検証したCSC社のルールでは同じでした。
2019.11.25

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS WAFマネージドルール内のルールIDが、異なるAWSアカウントでも共通か確認しました。結果をお伝えすると、少なくとも検証したCSC社のルールでは同じでした。

AWS WAFマネージドルール内のルールIDとは?

WAFを利用していると、正しいユーザーの通信をブロックしてしまうことがあります。誤検知時の対応として、個々のルールを例外登録できます。マネージドルール全体ではブロックし、例外登録したルールではカウントにするといったことが可能です。例外登録については以下のブログが詳しいです。

[新機能]AWS WAFマネージドルールで誤検知対応できる例外ルールの設定が可能になりました

例外登録するIDが異なるAWSアカウントのWeb ACLでも共通なのか検証し、同じであることを確認しました。

AWSアカウントが異なる場合でも、ルールIDが共通だと何が嬉しいのか?

検証環境でテストを行いAWS WAFで誤検知が発生した場合、検証環境にルールの例外登録を行うかと思います。本番環境への反映について、同じルールIDで例外登録できます。新機能のリリース前に検証環境でテストをしてAWS WAFの誤検知を見つけたら、本番環境に容易に反映できることになります。

検証手順

ここまでで本記事の趣旨は終わりですが、検証した手順をご紹介します。異なるAWSアカウントにWeb ACLを作成し、Cyber Security Cloud Managed Rules for AWS WAF Classic -OWASP Set-を割り当てました。ウェブ ACL トラフィック情報のログ記録を有効にしておきます。Web ACLはALBに適用しました。

XSSのテストコードの送信

WebブラウザのURLにhttp://alb-dnsname/?<script>alert(document.cookie)</script>を入力します。AWS WAFでブロックされ、ブロック画面「403 Forbidden」が表示されます。

Athenaでのログ確認

AWS WAFのログを見て、どのルールIDでブロックされたのか確認します。素のログをそのまま見るのは骨が折れるため、Athenaを利用します。Athenaコンソールでテーブル「waflogs_201911」を作成します。

CREATE EXTERNAL TABLE IF NOT EXISTS waflogs_201911
(
`timestamp` bigint,
formatVersion int,
webaclId string,
terminatingRuleId string,
terminatingRuleType string,
action string,
httpSourceName string,
httpSourceId string,
ruleGroupList array < struct <
    ruleGroupId: string,
    terminatingRule: string,
    nonTerminatingMatchingRules: array < struct < action: string, ruleId: string > >,
    excludedRules: array < struct < exclusionType: string, ruleId: string > >
> >,
rateBasedRuleList array < struct < rateBasedRuleId: string, limitKey: string, maxRateAllowed: int > >,
nonTerminatingMatchingRules array < struct < action: string, ruleId: string > >,
httpRequest struct <
    clientIp: string,
    country: string,
    headers: array < struct < name: string, value: string > >,
    uri: string,
    args: string,
    httpVersion: string,
    httpMethod: string,
    requestId: string
>
)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://[バケット名]/';

ActionがBlockかつ,自分のIPアドレスのログを抽出します。

SELECT from_unixtime(timestamp/1000, 'Asia/Tokyo') AS JST, * FROM waflogs_201911 WHERE action = 'BLOCK' and httpRequest.clientIp='xx.xx.xx.xx';

ログは以下のように確認できます。

rouleGroupList内のterminatingRule.ruleIdが個々のルールIDになります。

異なるAWSアカウントでも同様の操作を行い、同じルールIDが表示されることを確認しました。参考までに、本環境を土日の間放置していたところ、海外から攻撃と思われる通信が残っていました。そちらについても同様の通信が同じルールIDで記録されていました。

さいごに

AWS WAFマネージドルール内のルールIDが異なるAWSアカウントでも、共通なのか確認しました。同じ通信を同じルールIDで検知していたことから、アカウントが異なる場合でもルールの例外登録が簡単にできることを確認しました。