AWS WAFの誤検知を見つけ、Athenaを使って解消してみよう
AWS WAF（Web Application Firewall）は、Webアプリケーションを保護する強力なツールですが、誤検知が発生すると正当なトラフィックがブロックされ、ユーザーの利用に悪影響を及ぼすことがあります。
本記事では、Athenaを活用して誤検知の原因を効率的に特定し、解消する方法を解説します。ログデータを分析し、具体的な改善手順を学ぶことで、AWS WAFの設定を最適化しましょう。
この記事の目次
AWS WAF の使用例と注意点
AWS WAFは、AWS環境で稼働するWebアプリケーションを保護するためのクラウドネイティブなセキュリティツールです。
例えば 次の図のようにAWS WAF をApplication Load Balancer（ALB） と連携させることができます。
一方で、WAFには誤検知のリスクが存在します。例えば、正当なユーザーのリクエストが不審なトラフィックと誤って判断され、アクセスがブロックされることがあります。
では、上記図の構成を実際に構築し、誤検知がどのようなものなのかを具体的に見てみましょう。
アクセスログの解析と誤検知の確認
誤検知を実際に確認するには、一度誤検知を意図的に発生させ、アクセスログを解析する必要があります。手順は以下の通りです。
- CDKスタックでインフラを構築
- 誤検知を意図的に発生させるための設定
- AWS WAFにマネージドルールグループを適応するための設定
- Athenaを使ってログを分析
CDKスタックでインフラを構築
本検証環境はCDKスタックを用いてインフラ環境を構築しています。
```
import * as cdk from "aws-cdk-lib";
import { aws_ecs as ecs } from "aws-cdk-lib";
import { ApplicationLoadBalancedFargateService } from "aws-cdk-lib/aws-ecs-patterns";
import { Construct } from "constructs";
export class ApplicationStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const applicationLoadBalancedFargateService =
new ApplicationLoadBalancedFargateService(this, "sample", {
desiredCount: 1,
taskImageOptions: {
image: ecs.ContainerImage.fromRegistry(
// レジストリは必要に応じて書き換え
// WAF のブロックを確認したいだけならこのままでも OK
"public.ecr.aws/nginx/nginx:latest"
),
},
});
// WAF
const webACL = new cdk.aws_wafv2.CfnWebACL(this, "main", {
defaultAction: {
allow: {},
},
scope: "REGIONAL",
visibilityConfig: {
cloudWatchMetricsEnabled: false,
metricName: "waf-main-metrics",
sampledRequestsEnabled: true,
},
name: "waf-main",
rules: [
{
name: "AWS-AWSManagedRulesCommonRuleSet",
priority: 0,
statement: {
managedRuleGroupStatement: {
name: "AWSManagedRulesCommonRuleSet",
vendorName: "AWS",
excludedRules: [],
},
},
visibilityConfig: {
cloudWatchMetricsEnabled: true,
metricName: "AWS-AWSManagedRulesCommonRuleSet",
sampledRequestsEnabled: true,
},
overrideAction: {
none: {},
},
}
],
});
const wafPolicy = new cdk.aws_wafv2.CfnWebACLAssociation(
this,
"main-association",
{
webAclArn: webACL.attrArn,
resourceArn:
applicationLoadBalancedFargateService.loadBalancer.loadBalancerArn,
}
);
// WAFログ用S3バケット
const bucket = new cdk.aws_s3.Bucket(this, "awsWafLogsBucket", {
bucketName: `aws-waf-logs-${this.account}-bucket`,
removalPolicy: cdk.RemovalPolicy.DESTROY,
blockPublicAccess: cdk.aws_s3.BlockPublicAccess.BLOCK_ALL,
encryption: cdk.aws_s3.BucketEncryption.S3_MANAGED,
})
// WAFログ出力設定
const logConfig = new cdk.aws_wafv2.CfnLoggingConfiguration(
this,
"wafV2LoggingConfiguration",
{
logDestinationConfigs: [bucket.bucketArn],
resourceArn: webACL.attrArn,
}
)
}
}
```
ALBへのリクエスト処理の検証
本検証環境では、外部のクライアントからALBに対して `POST:/api/files` の URI で base64 に変換された画像ファイルをリクエストボディに詰めて、アップロードする処理を行なっています。
AWS WAFにマネージドルールグループを適応するための設定
AWS WAF に、ベースラインルールグループのコアルールセット (CRS) マネージドルールグループ（AWS-AWSManagedRulesCommonRuleSet）を適応させます。
Athenaを使ってログを分析
マネージドルールグループを適応するまでの設定を終わらせた後、アクセスログを貯めるためにAWS WAFを関連づけたALBを1日放置しました。その後、AWS以下のサイトをを参考に Athena のテーブルを作成して、放置して取得されたログを次のクエリで解析すると、キャプチャ画像のような結果が得られます。
AWS「AWS WAF ログをクエリする」https://docs.aws.amazon.com/ja_jp/athena/latest/ug/waf-logs.html（2025/2/21確認）
```
SELECT
COUNT(*) AS count,
terminatingruleid,
httprequest.httpmethod,
httprequest.uri
FROM waf_logs
WHERE action='BLOCK'
GROUP BY webaclid, terminatingruleid, httprequest.uri, httprequest.httpmethod
ORDER BY count DESC
LIMIT 100;
```
クエリの結果から、攻撃と思しきリクエストに混ざり、こちらで用意した`POST:/api/files` が検知されていました。
誤検知の疑いがあるので、より詳細を次のクエリで確認してみます。
```
SELECT
action,
httprequest.uri,
labels,
oversizefields
FROM waf_logs
WHERE action='BLOCK'
and httprequest.uri='/api/files'
LIMIT 100;
```
以下のAWSのサイトの `SizeRestrictions_BODY` の解説を見てみると、「8 KB (8,192 バイト) を超えるリクエストボディを検査します。」とあります。このことから、Athena で確認された `POST:/api/files` はリクエストボディに大きなファイルを入れた際に誤検知で Block されていることがわかりました。
AWS「コアルールセット (CRS) マネージドルールグループ」https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-baseline.html#aws-managed-rule-groups-baseline-crs（2025/2/21確認）
誤検知解消のためのルール編集
上記の方法で、`POST:/api/files` が誤検知で Block されていることがわかったので、次はこのリクエストの時は. `SizeRestrictions_BODY` でブロックしないようにする設定をします。
具体的な手順は以下の通りです。
1.カウントモードを設定する
1-a CDKで設定する場合
1-bマネジメントコンソールで設定する場合
2.Athenaでクエリを確認する
カウントモードを設定する
AWS WAF のカウントモードを使うことで、特定のルールによるブロックを解除することができます。カウントモードで設定をすることで、ルール一致時に検知はするがリクエストの「許可」も「拒否」も行わないようになります。
1-a CDKで設定する場合
CDKでカウントモードの設定をする場合は、WAF の rule の部分を次のように書き換えます。
```
rules: [
{
name: "AWS-AWSManagedRulesCommonRuleSet",
priority: 0,
statement: {
managedRuleGroupStatement: {
name: "AWSManagedRulesCommonRuleSet",
vendorName: "AWS",
// excludedRulesを追加
excludedRules: [{ name: "SizeRestrictions_BODY" }],
},
},
visibilityConfig: {
cloudWatchMetricsEnabled: true,
metricName: "AWS-AWSManagedRulesCommonRuleSet",
sampledRequestsEnabled: true,
},
overrideAction: {
none: {},
},
}
]
```
1-bマネジメントコンソールで設定する場合
マネジメントコンソールで変更したい場合は次のように設定します。
1. ルール編集画面を開く
2. カウントモードにしたいルール（今回はSizeRestrictions_BODY）のプルダウン選択項目を変更
3. 保存
4. ルール詳細でそのルールが `Override: Count` となっていれば OK
Athenaでクエリを確認する
カウントモードに設定した後に Athena のクエリをもう一度確認してみると、設定してから、`POST:/api/files` のリクエストが AWS WAF を通過していることがわかりました。
まとめ
ここまでで AWS WAF が誤検知をしていないか確認する方法や、誤検知を解消する方法の例をご紹介しました。
実際に AWS WAF を運用する際は、定期的にブロックされたアクセスを確認して内容を解析する必要があります。また、必要以上にリクエストを許可してしまわないよう気をつけてルールを編集する必要があります。マネージドルールを使用している場合は、ルールを用意しているベンダーに問い合わせながら誤検知を解消するといったことも検討してください。
WAF はセキュリティレベルの向上にとても有効なツールですが、その運用には専門的な知識が必要です。適切な運用体制を用意しておかないと費用をかけて導入したものの、誤検知だらけでユーザビリティに悪影響を与えたり、意味のあるルールを設定できず何も守れていないといった事態になりかねません。
とりあえず WAF を導入したから安心と思ってしまうのは危険です。自社で運用が難しい場合はアウトソーシングも検討しましょう。
ベアサポートでは、インフラエンジニアがお客様の要望に応じて柔軟にサポートする「マモル マネージドプラス」や、AWS WAFのマネージドサービスである「Cloudbric WMS for AWS WAF」など、AWS WAFの運用を助けるサービスを提供しています。ぜひお気軽にご相談ください。
参考資料
・AWS 「Web アプリケーションにおける Amazon ECS / AWS Fargate アーキテクチャデザインパターン」https://aws.amazon.com/jp/builders-flash/202409/web-app-architecture-design-pattern/（2025/2/21確認）
・DevelopersIO 「S3に保存したAWS WAFログをAthenaで分析してみたhttps://dev.classmethod.jp/articles/analyzing-waflogs-with-athena/（2025/2/21確認)
・AWS「AWS WAF ログをクエリする」https://docs.aws.amazon.com/ja_jp/athena/latest/ug/waf-logs.html（2025/2/21確認）
