AWS WAFをどのように導入するか

「セキュリティも不安だし、そろそろウチにもWAFを入れてみようか。」

クラウド以前のWAFは非常に高価でしたが、最近は廉価なWAFも増えています。 その中でもAWS WAFは非常に低価格で簡単に試すことができるので、非常にオススメです。
本記事では、AWS WAF導入時に必要なステップを解説します。

今回は以下のようなWebサーバ構成にAWS WAF導入するという例を想定します。

Webサーバ前段にロードバランサーがありますが、防御的な効果はほぼ無いため、SQLインジェクション等の不正アクセスのWebリクエストは、EC2インスタンス上で動いているWebアプリケーションに到達します。

もちろん、セキュリティに気を配って、アプリケーションやミドルウェアなどが構成されていれば、不正アクセスが成功することは少ないと思います。
しかし、セキュリティに絶対は無いため、防御レベルを上げるためにAWS WAFの導入を検討します。

ステップ１. AWS WAFをどこで動作させるか決める

AWS WAFは、ALB（ロードバランサー）またはCloudFront（CDN）のオプションのような形で動作します。
実はAPI GatewayやAppSyncといったサービスとも協調して動作しますが、サーバレスの構成となるため、今回は考慮しません。

いずれにしても、Webサーバ前段で不正アクセスを緩和してくれることになります。
なお、WAFの文脈では緩和（Mitigate）という言葉もよく出てくるのですが、完全に止めることを保証していないためと思われます。

パターン１）ALBで動作させる

パターン２）CloudFrontで動作させる

ステップ２. どのルールグループを使うか決める

AWS WAFとはサービス名で、実際にALBやCloudFrontに適用するのは、WebACL（Web Access Control List）という単位になります。 このWebACLにどのようなアクセスを不正アクセスとみなすかというルールを適用します。

ただし、「どのようなアクセスパターンをSQLインジェクションとみなすか」というところまでは深く考える必要はなく、基本的には既に用意されたルールセットの中から選択することになります。

また、下記にあげた4パターンは、どれか1つだけである必要はなく、組み合わせて使うことも可能です。

パターン１）AWSマネージドルール・ルールグループを使う

おそらく、導入が一番簡単で価格も安いのが、このパターンです。 AWSの用意した下記11個のルールグループの中から、自分のWebアプリケーションを守るために役に立ちそうなルールを選択します。

「データベースを使ったサービスか」「OSは何か」「PHP使っているか」「WordPress使っているか」などがわかれば、それほど悩まずに選択できると思います。 利用するルールグループの数で利用料は変わりますが、1ルールグループで1USD/月なので、あまり気にしないでいい気がします。 （ルールグループ利用料以外にも、AWS WAFの利用料は必要ですが、それは後述します。）

なお、各ルールグループにはWCU（WebACLキャパシティユニット）が定められていて、合計1500までとなっています。 ただ、上限緩和は可能です。

ルールグループ	概要	WCU
コアルールセット	ウェブアプリケーションに一般的に適用可能なルールが含まれています。これは、ハイリスクおよび OWASP出版物。すべての AWS WAF ユースケースでこのルールグループを使用することを検討してください。	700
管理者保護	公開されている管理ページへの外部アクセスをブロックするためのルールが含まれています。	100
既知の不正な入力	無効であることがわかっており脆弱性の悪用または発見に関連するリクエストパターンをブロックするルールが含まれています。これにより、悪意のあるアクターが脆弱なアプリケーションを発見するリスクを軽減できます。	200
SQL データベース	SQL インジェクション攻撃などの SQL データベースの悪用に関連するリクエストパターンをブロックするルールが含まれています。これにより、不正なクエリのリモートインジェクションを防ぐことができます。	200
Linux オペレーティングシステム	Linux 固有のローカルファイルインクルージョン (LFI) 攻撃など、Linux 固有の脆弱性の悪用に関連するリクエストパターンをブロックするルールが含まれています。	200
POSIXオペレーティングシステム	POSIX および POSIX と同等のオペレーティングシステムに固有の脆弱性の悪用 (ローカルファイルインクルージョン (LFI) 攻撃など) に関連するリクエストパターンをブロックするルールが含まれています。	100
Windows オペレーティングシステム	Windows 固有の脆弱性の悪用に関連するリクエストパターンをブロックするルールが含まれています。	200
PHPアプリケーション	安全でない PHP 関数のインジェクションなど、PHP プログラミング言語の使用に固有の脆弱性の悪用に関連するリクエストパターンをブロックするルールが含まれています。	100
WordPress アプリケーション	WordPressサイトに固有の脆弱性の悪用に関連するリクエストパターンをブロックするルールが含まれています。	100
AmazonIPレピュテーションリスト	Amazon内部脅威インテリジェンスに基づくルールが含まれています。これは、通常ボットやその他の脅威に関連付けられているIPアドレスをブロックする場合に役立ちます。	25
匿名IPリスト	視聴者IDの難読化を許可するサービスからの要求をブロックするルールが含まれています。これには、VPN、プロキシ、Torノード、およびホスティングプロバイダー（AWSを含む）からのリクエストが含まれます。	50

AWSマネージドルール・ルールグループの詳細はAWS Managed Rules rule groups リストをご確認ください。

パターン２）AWS以外のマネージドルール・ルールグループを使う

ここでは深く解説しませんが、AWS以外のベンダーが提供しているマネージドルール・ルールグループもあります。 AWSのものと比べて、別途マーケットプレイスで費用が発生しますが、興味のある方は検討してみてください。

docs.aws.amazon.com

パターン３）AWS WAF セキュリティオートメーションを使う

AWSが提供しているものですが、提供形態がマネージドルールではなく、CloudFormationテンプレートとなります。

aws.amazon.com

2020 年 11 月公開のバージョン 3.1.0では、以下のルールが適用されたWebACLが作成されます。

ルールグループ	概要
AWS-AWSManagedRulesCommonRuleSet	AWS マネージドルール マネージドルールのコアルールセットと同じ
(スタック名)WhitelistRule	手動 IP リスト 許可する IP アドレスを手動で追加できます。
(スタック名)BlacklistRule	手動 IP リスト ブロックする IP アドレスを手動で追加できます。
(スタック名)HttpFloodRateBasedRule	HTTP フラッド ウェブレイヤーの DDoS 攻撃や総当たりのログインの試行など、特定の IP アドレスからの大量の要求からなる攻撃から保護します。
(スタック名)ScannersAndProbesRule	スキャナーとプローブ アプリケーションアクセスログを解析して、オリジンによって生成された異常な量のエラーなどの疑わしい動作を検索します。それらの疑わしいソースの IP アドレスをお客様が定義した期間ブロックします。
(スタック名)IPReputationListsRule	IP 評価リスト ブロックする新しい範囲について、毎時サードパーティーの IP 評価リストをチェックする IP リストパーサー AWS Lambda 関数です。
(スタック名)BadBotRule	悪意のあるボット 試みられた攻撃をおびき寄せることを目的としたセキュリティメカニズムであるハニーポットを自動的に設定します。
(スタック名)SqlInjectionRule	SQL インジェクション URI、クエリ文字列、リクエストボディ内の一般的な SQL インジェクション
(スタック名)XssRule	XSS URI、クエリ文字列、リクエストボディ内の一般的な クロスサイトスクリプティング

HTTP Flood Protectionというような、一定期間のリクエスト数が閾値を超えたらブロックといった機能が実装されているのが特徴です。

ただし、AWS WAF セキュリティオートメーションを使わなくても、自分でレートベースのルールステートメントを作成し、WebACLに追加すれば、同様のことは可能です。

パターン４）WafCharmを使う

サイバーセキュリティクラウド社の提供するWafCharmというサービスがあります。

www.wafcharm.com

こちらを利用すると、ルールは自動的に設定されるため、自分で考える必要はありません。 どのようなルールが含まれているかというと、もちろんSQLインジェクションやXSSのような一般的な不正アクセスや不正IPリストでのブロックも含まれています。

検知精度についてAWSのマネージドルール等との比較し評価することは難しいですが、以下のようにWAFサービスの提供では実績が高い会社のサービスなので、期待できる気はします。

サイバーセキュリティクラウドは、自社で一貫してWebセキュリティサービスの開発・運用・保守・販売を行っています。当社では、クラウド型WAF「攻撃遮断くん」とAWS WAFのルール自動運用サービス「WafCharm（ワフチャーム）」をサービス提供しています。 クラウド型WAF「攻撃遮断くん」はWebサイトへのサイバー攻撃を可視化・遮断するWebセキュリティサービスです。国内における導入サイト・導入社数No.1の実績を誇ります。 AWS WAF自動運用サービス「WafCharm（ワフチャーム）」は、「攻撃遮断くん」で培った数千億件のビッグデータを基に、お客様のシステム構成やアクセス状況から、AIが最適なシグネチャを自動判別・自動運用いたします。
https://www.wafcharm.com/aws-waf-managed-rules/

もっとも、WafCharmの優位点は「日本語でサポート」「シグニチャ作成もサポート範囲に含まれる」ことだと思っています。 WAFの運用面での考慮点は後述します。

欠点は、AWS WAFの料金とは別にWafCharmの料金が必要になることです。

また、ルールの数が30程度とマネージドルールと比べると多いため、AWS WAFの料金も少し多めになります。

ステップ３. 追加のルールが必要か確認する

上記で選択したルールグループの他に追加したいルールがあるかを確認します。
以下はよく設定される例です。

• 地理的一致（特定の国からのみ許可、特定の国からは拒否、など）
• IP セット一致（管理用URLへのアクセスはオフィスからのみ許可、など）

docs.aws.amazon.com

ステップ４. AWS WAF利用料の見積もりをする

AWS WAFの料金は、固定部分（Web ACL数、ルール数）と従量部分（リクエスト数）で構成されます。

リソースタイプ	料金
Web ACL	5 USD /月
ルール	1 USD /月
リクエスト	0.6 USD /100 万リクエスト

aws.amazon.com

ルール料金

ルールグループには複数のルールが含まれていて、各ルールで1USD/月となります。

ただし、マネージドルールグループの中のルールは課金されずにマネージドルールで1USD/月となります。例えば、コアルールセット・ルールグループのように約20ルールを含んでいたとしても、1USD/月です。

実際にルールの数を数えてみると、以下の感じでした。

• AWSマネージドルール・ルールグループだけ使う場合は、10USD程度
• セキュリティオートメーションだけ使う場合は、10USD程度
• WafCharmだけ使う場合は、30USD程度

リクエスト料金

Webアプリケーションによっては、ブラウザが1回アクセスするだけで数十リクエストとなることもあります。
ただ、100万リクエストあたり0.6 USDなので、かなり多くのリクエストを受けるWebアプリケーションでない限りはあまり気にしないでいいレベルだと思われます。

とはいえ、できれば事前に確認することをオススメします。

CloudFrontの場合は、マネージメントコンソールでCloudFront 使用状況レポート - Amazon CloudFrontを見れば、過去１ヶ月のリクエスト総数を確認できます。

ALBの場合は簡単に確認できる方法は無さそうですが、アクセスログを保存しているS3バケットをAthenaで検索し、行数をカウントすれば確認できます。

ステップ５. 正常なアクセスパターンでテストをする

誤検知とは

AWS WAFに限らず、WAFの話題になると誤検知という言葉がよくでます。
誤検知とは正常なアクセスを不正アクセスと誤って検知してしまうことです。

不正アクセス検知時にブロックするという設定になっている場合に、エンドユーザーからのリクエストが誤検知と判定されると、サービスを使えなくなってしまいます。
そのようなことがないように事前にテストをします。

パターン１）カウントモードでテストをする

カウントモードとは

本番環境、または開発環境でAWS WAFをカウントモードで動作させます。 カウントモードとは、不正アクセス検知時にログに記録するだけのモードです。 リクエストをブロックはしません。

正常なアクセスパターンを一通り試して、テストマシンのIPアドレスでログを検索し、不正アクセスと検知されていなければ誤検知はされないと判断できるでしょう。

なお、「テストしてください」と依頼をすると、いくつかのページを表示させるだけで済ませようとする人がいますが、エンドユーザーが行う動作はなるべく網羅するようにすることをお勧めします。
特にPOSTメソッド（ブラウザからサーバへ書き込んだり、ファイルをアップロードしたり）が不正アクセスと検知されやすいので、しっかりテストしましょう。

パターン２）ブロックモードでテストをする

テストする人とログを確認する人が別々な場合があります。
そのような場合、ブロックモードでテストした方が誤検知の発生時にすぐわかるのでやりやすいというケースもあります。 とはいえ、本番環境でいきなりブロックにするとエンドユーザーに影響がでる可能性があるので、テスト用環境を作成します。（下図の赤線で囲った部分）

また、場合によっては、SSL証明書やDNSなどの設定も必要になります。

WAFのログからどのルールが原因か特定する

例として、以下のようなアクセスがあり、WAFルールで不正アクセスと検知されブロックされたとします。

~$ curl "http://www.example.com/index?q=<script>alert('swxtest')</script>"
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
</body>
</html>

このWebリクエストに関するWAFログのterminatingRuleの部分を確認すると、どのルールグループの中のどのルールで誤検知されたかを特定できます。

    {
      "ruleGroupId": "AWS#AWSManagedRulesCommonRuleSet",
      "terminatingRule": {
        "ruleId": "CrossSiteScripting_QUERYARGUMENTS",
        "action": "BLOCK",
        "ruleMatchDetails": null
      },

ステップ６. 誤検知の対処をする

なんらかの誤検知が出てしまった場合にどうするかです。
いくつか対応パターンをあげてみます。

パターン１）ホワイトリストに入れる

管理画面ページへのアクセスで誤検知が起きた場合、そこにアクセスするのが特定IPアドレスだけであった場合は、ホワイトリストにIPアドレスを追加します。

パターン２）該当ルールだけカウントモードにする

ルールグループ全体でカウントモードにすることもできますし、その中の1つのルールだけをカウントモードにすることもできます。 手っ取り早いですが、そのルールが効かなくなるので、防御レベルは落ちます。

パターン３）該当ルールを更に条件づけを細かく設定する

通常はルールはある条件に合致した時にブロックと設定されています。 これはRule builderで設定できます。

ただし、マネージドルールのカスタマイズできません。

パターン４）Webアプリケーションの修正・仕様変更をする

Webアプリケーションを誤検知されにくい仕様・実装に変更するという方法も考えられます。

ステップ７. 継続的な運用をする

テストが完了し、誤検知の対応も完了すると、本番環境でブロックモードで利用が開始されます。 その後は、以下のような対応が必要になることもあります。

• テストケース漏れの影響
  • テストケースから漏れていたアクセスパターンで誤検知が発生する。
• アプリケーションの更新の影響
  • 新機能が追加された場合に、そこで誤検知が発生する。
• WAF側のルール更新の影響
  • マネージドルールや機械学習によるルール更新で、誤検知が発生する。

ただ、実際は心配していたほどは、新たな誤検知は起こらない場合がほとんどです。
あまり心配しすぎない方がいいと思います。

とはいえ、何かあった時に対応できる体制を確保しておきたいところです。
社内で体制を作るのが難しければ、WafCharmのサポートをつけるのもいいかもしれません。

渡辺 信秀(記事一覧)

2017年入社 / 地味な内容を丁寧に書きたい