こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。
みなさん、AWS WAFは使ってますか？
本日、AWS WAFにアップデートが来ました。
AWS WAFのログに出力される rulesMatchDetails が正規表現ルールに対応したようです。
従来、このフィールドはSQLインジェクションとXSSのルールのみに対応していました。
ざっくりまとめ
- AWS WAFのログフィールド
rulesMatchDetailsが正規表現のルールにも対応するようになった。rulesMatchDetailsにはリクエストに一致したルールマッチに関する詳細情報が出力される。rulesMatchDetailsは今までSQLインジェクションとXSSのルールにしか対応していなかったが、今回正規表現のルールに対応するようになった。
- 何が嬉しいのか？
- 正規表現ルールにマッチしたリクエストのログで、「どういう文字列がルールに引っ掛かったのか」を簡単に確認出来るようになった。
確認してみた
今回のアップデート内容で挙げられている rulesMatchDetails ですが、厳密には以下の3つのフィールドが今回のアップデートに該当します。
- nonTerminatingMatchingRules
- ruleMatchDetails
- terminatingRule
- ruleMatchDetails
- terminatingRuleMatchDetails
ログフィールドの詳細は下記ドキュメントをご参照ください。
追記：2024年3月4日
追記時点では、上記フィールドが正規表現に対応しているという旨の内容が下記ドキュメントから削除されています。
それでは実際に確認してみます。
今回は検証環境としてECSでDVWAを立てました。ECSの前段にALBを配置し、そこにWAFのWeb ACLをアタッチしています。
Web ACLにアタッチしたルールは以下の通り。
- AWS-AWSManagedRulesSQLiRuleSet
- AWS-AWSManagedRulesCommonRuleSet
- manage-path-rule
- 特定のパスへのリクエストを制限する正規表現を用いたカスタムルール
元々対応していたSQLインジェクション、元々対応していなかったルールのリクエスト、今回対応した正規表現ルールのリクエストを投げて確認していきます。
元々対応していたSQLインジェクションを実行してみる
まずはSQLインジェクションのリクエストを飛ばしてみます。マッチしたリクエストへのアクションとしてBLOCKを設定。
ログを確認します。SQLインジェクションは従来より rulesMatchDetails に対応しているはずです。
{
"timestamp": 1709012056392,
"formatVersion": 1,
"webaclId": "arn:aws:wafv2:ap-northeast-1:123456789012:regional/webacl/test-web-acl/151ac448-c89f-4335-b49e-69d6fafb1036",
"terminatingRuleId": "AWS-AWSManagedRulesSQLiRuleSet",
"terminatingRuleType": "MANAGED_RULE_GROUP",
"action": "BLOCK",
"terminatingRuleMatchDetails": [
{
"conditionType": "SQL_INJECTION",
"location": "ALL_QUERY_ARGS",
"matchedData": [
"1",
"or",
"1",
"=",
"1"
],
"matchedFieldName": "id",
"sensitivityLevel": "LOW"
}
],
"httpSourceName": "ALB",
(以下略)ログの上部に terminatingRuleMatchDetails として、どの文字列が引っ掛かったのかの情報が出力されています。
対応していないヘッダー「UserAgent」レスのリクエストを実行してみる
「User Agent」がヘッダーに無いリクエストは AWSManagedRulesCommonRuleSet の NoUserAgent_HEADER というルールでチェック出来ます。
それではcurlを使って「User Agent」ヘッダーを空にしてリクエストを投げてみます。
$ curl 'http://******.ap-northeast-1.elb.amazonaws.com/' -H 'User-Agent:'
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
</body>
</html>それではログを確認します。
{
"timestamp": 1709016042091,
"formatVersion": 1,
"webaclId": "arn:aws:wafv2:ap-northeast-1:123456789012:regional/webacl/test-web-acl/151ac448-c89f-4335-b49e-69d6fafb1036",
"terminatingRuleId": "AWS-AWSManagedRulesCommonRuleSet",
"terminatingRuleType": "MANAGED_RULE_GROUP",
"action": "BLOCK",
"terminatingRuleMatchDetails": [],
"httpSourceName": "ALB",仕様通り、ルールには引っ掛かりましたが terminatingRuleMatchDetails には何も出力されていません。
今回対応した正規表現ルールのリクエストを実行してみる
それでは最後に今回のアップデート内容を確認します。
下記のような正規表現を使った、特定パスへのリクエストを制限するカスタムルールを作成しました。
ブラウザで上記文字列を含むパスへアクセスしたところ、ブロックされ403が返ってきました。それではログを確認します。
{
"timestamp": 1709014304652,
"formatVersion": 1,
"webaclId": "arn:aws:wafv2:ap-northeast-1:123456789012:regional/webacl/test-web-acl/151ac448-c89f-4335-b49e-69d6fafb1036",
"terminatingRuleId": "manage-path-rule",
"terminatingRuleType": "REGULAR",
"action": "BLOCK",
"terminatingRuleMatchDetails": [
{
"conditionType": "REGEX",
"location": "URI",
"matchedData": [
"/vulnerabilities/sqli"
],
"matchedFieldName": ""
}
],
"httpSourceName": "ALB",SQLインジェクションと同様に terminatingRuleMatchDetails が出力されていることが分かりますね。
追記：2024年3月4日
本アップデートのアナウンスページが消えていたため、気になって挙動を再確認してみました。
追記時点では、正規表現は terminatingRuleMatchDetails として検知されるものの、matchedData の中身は下記のように正確に出力されないパターンがあるようです。下記出力は、記事執筆時点のルールと同条件のものを使用したものです。
"terminatingRuleMatchDetails": [
{
"conditionType": "REGEX",
"location": "URI",
"matchedData": null,
"matchedFieldName": ""
}
],まとめ
WAFを運用するにあたって、「リクエストのどの内容がどのルールに引っ掛かったのか」が出来ることは非常に有用です。
今回は多様な文字列のチェックに用いられる正規表現ルールにサポートしたということで、多くの方が恩恵を受けるアップデートなのではないでしょうか。
本記事がどなたかのお役に立てれば幸いです。
以上、べこみんでした。
5
