Zenn
RYDE株式会社Publicationへの投稿
🛡️

AWS WAF はじめの一歩 〜導入から運用開始まで〜

fumiki
に公開
1
AWS
CloudFront
Security
WAF
Cyber Security
tech

はじめに

RYDE 社が開発するサービスでは Web アプリケーションファイアウォールとして AWS WAF を使用しています。

RYDE PASS の詳細はこちらをご覧ください

https://zenn.dev/ryde/articles/5c2ba40d930577

本記事では特に初期導入時のポイントをわかりやすく解説するため、基本的なコアルールセット(CRS)を中心に説明していますが、実際の運用ではより包括的な保護を実現するために複数のマネージドルールセットを組み合わせることをお勧めします。
WAF の導入を検討している方の参考になれば幸いです。

📋 目次

  1. AWS WAF とは
  2. WAF が必要な理由
  3. マネージドルールの選定と組み合わせ
  4. カウントモードとブロックモード
  5. 具体的な導入手順
  6. ログを分析する
  7. ブロックモードへの移行
  8. まとめ

AWS WAF とは

AWS WAF は、Web アプリケーションを様々な攻撃から保護するためのファイアウォールサービスです。
Application Load Balancer(ALB)や CloudFront の前段に配置することで、不正なリクエストをブロックできます。

主な特徴として：

  • SQL インジェクションや XSS などの一般的な攻撃をブロック
  • 特定の IP アドレスからのアクセス制御
  • リクエストの内容に基づいたフィルタリング
  • 複数の AWS マネージドルールを組み合わせた多層防御の実現
  • カスタムルールによる業務特有のセキュリティ要件への対応

があります。

WAF が必要な理由

Web アプリケーションの規模拡大やトラフィック増加に伴い、セキュリティ対策の重要性も高まってきます。
WAF 導入を検討する一般的な理由としては、以下のような点が挙げられます：

  • 一般的な攻撃パターン（SQL インジェクション、XSS など）への基本的な防御
  • 監視ログのノイズ削減による運用負荷の軽減
  • セキュリティ対応の自動化による効率化

マネージドルールの選定と組み合わせ

まず、WAF で使用される基本的な用語について簡単に説明します：

  • ルール：特定のリクエスト特性（URL パス、ヘッダー値、IP アドレスなど）に基づいて、そのリクエストを許可・ブロック・カウントするための個別の条件設定です。
  • マネージドルール：AWS によって作成・管理・更新されるルールのことで、自分でメンテナンスする必要がなく、最新の脅威に対応したルールを簡単に利用できます。
  • ルールセット（マネージドルールグループ）：特定の脅威カテゴリや保護目的のために複数のルールをまとめたグループです。例えば「コアルールセット(CRS)」は基本的な保護を提供するルールの集まりです。

AWS WAF には様々なマネージドルールが用意されています。効果的な防御のためには、これらを適切に組み合わせることが重要です。
本記事では主に初期導入としての「コアルールセット (CRS) マネージドルールグループ」について詳しく解説しますが、実際の本番環境ではより包括的な保護を検討することをお勧めします。

基本となるコアルールセット（CRS）

CRS は基本的な保護機能を提供し、WAF 導入の第一歩として適しています：

  • AWS が推奨する基本的な保護機能が含まれている
  • 誤検知のリスクが比較的低い
  • 運用実績が豊富

CRS に含まれる主要なルール例

ルール名 概要
NoUserAgent_HEADER User-Agent ヘッダーがないリクエストを検知
SizeRestrictions_BODY リクエストボディが大きすぎるものを検知
UserAgent_BadBots_HEADER 既知の悪意のあるボットを検知
CrossSiteScripting_BODY リクエストボディ内の XSS パターンを検知
SQLi_BODY SQL インジェクションの試みを検知
RestrictedFileNames_QUERYSTRING 危険なファイル名やパスのパターンを検知

カウントモードとブロックモード

WAF を本番環境に導入する際は、まず以下の 2 つの動作モードを理解しておくことが重要です：

  • カウントモード：ルールに一致するリクエストを検出・記録するだけで、ブロックはしません。導入初期の評価フェーズで使用し、実際のトラフィックへの影響なしに検知精度を確認できます。

  • ブロックモード：ルールに一致するリクエストを実際にブロックします。カウントモードでの十分な評価後に移行することで、誤検知による正常トラフィックのブロックリスクを軽減できます。

一般的な導入フローとしては、まずはカウントモードで導入し、トラフィックパターンを分析した後、段階的にブロックモードへ移行していきます。

具体的な導入手順

AWS WAF の導入は以下のステップで進めていきます。

ステップ 1: Web ACL を作成する

AWS のコンソールから "WAF & Shield" をクリックし、"Create Web ACL" から新規作成します。

設定内容のサンプルを見る

ステップ 2: Web ACL をカウントモードに設定

以下のように「Override rule group action to count」にチェックを入れることで、検知のみの状態で運用できます：

この設定により、本来ならブロックされるリクエストも通過させながらログに記録できるため、誤検知の可能性を評価できます。

ステップ 3: ログの出力を設定

"Sampled Requests" 機能を有効にすることで簡単にどのようなリクエストが WAF にハンドリングされたかを見ることはできますが、過去 3 時間分までしか見ることができません。しっかりと動作を評価するためには、Cloud Watch Logs や S3 との連携機能を使ってすべてのログを保存することが重要です。

Web ACL の"Logging and metrics"メニューからこの設定ができます。

設定時のポイントは以下になります。

  • COUNT されたアクセスのログを残すように設定する
  • Cloud Watch Logs のロググループの名称は "aws-waf-logs-" で始まる名前にする必要があるため、命名の際にご注意する
  • リクエストヘッダーに認証情報などのセキュアな情報が含まれる場合は削除するようにする

具体的な設定画面は以下を参照してください。

設定内容のサンプルを見る

ログを分析する

ある程度ログが溜まったら、カウントモードからブロックモードに移行できるか判断するためにログを分析します。

この時最も慎重に見るべきポイントは、"正常なリクエストが誤検知されていないか"ということです。
様々なパスに対して様々な攻撃が来るため、膨大なリクエストの中から正常なリクエストの誤検知を発見するのは骨の折れる作業です。

弊社では以下のようなクエリを使って、正常なパスへのリクエストにある程度絞り込むことで誤検知を発見しやすくしています。

# 本来有効なリクエストがブロックされていないかを確認するため、有効なパスの第一階層名でざっくり絞り込んだアクセスを見るためのクエリ

fields ruleGroupList.0.terminatingRule.ruleId as ruleId, httpRequest.uri as uri
| filter webaclId = "arn:aws:wafv2:ap-northeast-1:111111111111:regional/webacl/xxxxxx/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx" # 置き換えてください
| filter (
    uri = '/'
    or uri like /^\/users\/.*/
    or uri like /^\/admin\/.*/
  )
| stats count(*) as count by ruleId, uri
| sort by count desc
| limit 10000
クエリ結果のサンプルを見る

ここで誤作動が一切無いことが分かれば晴れてブロックモードへ移行できます。

もし正常なパスへのリクエストがどうしても特定のルールに引っかかってしまうということがあれば、
そのルールだけ解除する等の対処を行った上でのブロックモードへの移行を検討します。

ブロックモードへの移行

ステップ 1: ブロックモードを有効化する

Web ACL の編集画面で Override rule group にて Count モードの設定を解除します。

ステップ 2: ログの設定変更

これまでは「COUNT されたものがログに出力される」という設定だったので、
「BLOCK されたものがログに出力される」設定に変更します。

※ COUNT するルールと BLOCK するルールを混在させている場合は、どちらも残すように設定するのがおすすめです。

これでブロックモード移行後も対象となったリクエストのログが残ります。

ステップ 3: 動作確認

WAF が意図通りリクエストをブロックしてくれるか動作確認をしてみましょう。
一番簡単な方法は、User-Agent を空にして curl でリクエストを送ることです（NoUserAgent_HEADER ルールに引っかかります）。

curl https://xxxxxx.com -H 'User-Agent: '

以下のように 403 Forbidden レスポンスが返ってくれば、WAF が正常に機能していることが確認できます。

<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
</body>
</html>

まとめ

AWS WAF のマネージドルールである CRS を使って WAF を導入する手順をご紹介しました。
AWS WAF の導入は以下のステップで段階的に進めることをお勧めします：

  1. コアルールセット(CRS)からのスタート
  2. 十分な分析と評価の実施
  3. 必要に応じた追加の専用マネージドルールセットの検討
  4. ブロックモードへの移行

導入後も定期的にログ分析を行い、誤検知がないかモニタリングしましょう。
また、攻撃パターンの変化に応じて、より高度なルールセットの追加を検討するなど、WAF の保護機能を継続的に強化していくことをお勧めします。
この記事が皆様の導入検討の参考になれば幸いです。

1
RYDE株式会社
RYDE株式会社Publication

RYDE株式会社のテックブログです。 モビリティプラットフォーム「RYDE PASS」の開発・運用にまつわる技術的な知見を投稿します。 主な技術スタックは React / ReactNative / Next.js / Ruby on Rails / GraphQL / AWS などです。 【エンジニア積極採用中】

Discussion

ログインするとコメントできます