【AWS WAF】テンプレートでお手軽にWAFを構築しよう！【前編】

AWSでWAFを利用する場合、以下のような手段が選択できます。

• 外部のクラウドWAFを利用する
  • クラウドWAF専用のサービス
  • CDNに付帯するWAFサービス
• AWSのサービスであるAWS WAFを利用する
  • 自前でルールを作成する
  • WAFサードパーティのサービスと連携する
  • WAFサードパーティのマネージドルールを利用する(2017/11/29発表のサービス)
• AWSのホスト型仮想アプライアンスを利用する

上記はそれぞれ費用・品質・運用負荷・ネットワーク構成に対する適合性など、一長一短があります。 本ページでは、上記のうち費用が最も抑えられるであろう「AWS WAFを利用し自前でルールを作成する」方法について、テンプレートを用いながら素早く作成する方法をご説明します。

冗長性について考える必要はありません

• AWS WAFはサービスですので冗長性について気にする必要はありません。これは物理アプライアンス導入に比べて大きなメリットになります。対してAWSのホスト型仮想アプライアンスを導入する場合はインスタンスとして稼働しますので冗長化の考慮が必要になります。

おまかせ型のWAFではありません

• クラウドWAFや多くのアプライアンス製品は定期的なシグネチャ更新が行われるため、導入後は手放しで運用するケースが多いと思いますが、AWS WAFでは手放し運用は危険です。自分で定義した攻撃しか対応しませんので、Webサイトの追加タイミングやアタックパターンのトレンド変化などを見据えながら定期的に設定を見直していく必要があります。
  • 2017年11月30日に発表されたWAFのマネージドルールを利用する場合はこの限りではありませんが、ここでは割愛します。
• IPレピュテーションなどの一部の機能についてはLambdaを組み合わせることで自動更新が可能となりますが、新たな攻撃については自動で対応されることがありません。シグネチャの自動更新を行いたい場合は、WAFサードパーティとの連携や、アプライアンス、クラウドWAFを検討する必要があります。

設置できる場所が決まっています

• AWS WAFはCDN(CloudFront)とロードバランサ(ALB)に設置できます(※)。実際に位置で困った経験はありませんが、例えばオンプレのように「外側のFWでL3/L4の攻撃トラフィックを削ったうえで、内側で費用とスループットを抑えたWAF製品を導入する」といったアプローチは成り立ちません。
  • ※[追記]2018/11/5よりAPI Gatewayにも設置できるようになりました！
    • https://aws.amazon.com/jp/about-aws/whats-new/2018/10/amazon-api-gateway-adds-support-for-aws-waf/
• L3/L4のDDoSアタックについてはAWS WAFに統合されている「AWS Shield」によって大部分をブロックできますので、AWS WAFを導入するだけでシームレスに防御ができます。
• なお、CloudFrontに配置する場合はCloudFrontを経由せずに流入するアクセスについてはWAFが効きませんのでアクセス制御等の考慮が必要となります。
  • CloudFront経由のAWS WAFはブロックされた際の"403 Forbidden"エラーページをカスタマイズできるというメリットなどもあります。

主役はSQLインジェクションとクロスサイトスクリプティングの2つ！

• AWS WAFのルールのうち、SQLインジェクション(以下、SQLi)とクロスサイトスクリプティング(以下、XSS)の2つはサービスのなかでも扱いが違います。基本的にAWS WAFのシグネチャ(※)は引っ掛ける文字列から自分で定義する必要があり、それがAWS WAF導入ハードルが高いゆえんでもあるのですがSQLiとXSSについては文字列の定義が不要です。事前にサービスとして定義されており、細かいルールは見えないようになっています。Webサービスに対する攻撃の半数以上はこの2つで占められるとも言われていますので、ルール開示による回避を防ぐためにブラックボックス化されているのだと推察されます。
  • ※AWS WAFの正確な用語としてはConditionと呼ばれます

Webサイトによって向き不向きがあります

• AWS WAFの適用対象サイトには入力フォームがある場合がほとんどだと思いますが、フォームに入力される文字列にHTMLタグ名やjavascriptハンドラ名などの一部が含まれると、XSS攻撃と判定されブロックされてしまうケースがあります。XSSはフォームの入力結果の確認画面など、HTMLやjavascriptをサイト側で生成する箇所で発生するインジェクション攻撃です。タグ・ハンドラは沢山の名前が定義されている関係上、ブロックされる文字列は割と一般的で短い半角英単語・記号で構成されているようで、ブログ投稿や注文備考欄などのフリーフォーマットのフォームで何気ない英単語を入力した際などに意図しないブロックが発生することがあります。
• XSSのルールは上述したように定義を確認することもできないため原因把握が困難となります。自力による検証を繰り返してブロックされる文字列がおおよそ特定できた場合はAWS WAFのルール順序とアクションを工夫することで回避はできますが、慎重にルールを考慮しないとXSSの防御機能が無効化されることもあるので注意が必要です。
  • [追記] 2018年8月30日に機能が改善され、ブロック理由が把握できるようになりました！
• 個人的にはHTMLタグのフォーム入力が必然ともいえる「ブログ」などのCMSサイトへのAWS WAF適用はハードルが高いという印象です。

性能について

• デフォルトの制限値がありますが、上限緩和申請が可能です。http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/limits.html
• デフォルト制限値
  • ALBの場合
    • ウェブ ACL あたり 10,000リクエスト/秒
      • 1PV=20リクエストとすると、同時アクセス数500くらいがデフォルト上限の目安です
  • CloudFrontの場合
    • 1ディストリビューションあたり100,000リクエスト/秒
      • 単純にALBの10倍の許容力があります

費用について

• 以下公式サイトのとおり従量課金となります。
  • https://aws.amazon.com/jp/waf/pricing/
• 以下のウェブACLとルール、リクエスト料金を合算したものが費用になります。アプライアンスと比べると格段に安いことがおわかり頂けるかと思います。
  • ウェブACLとルール
    • ウェブACLとルールの料金は個数単位となるため、事前におおよその金額は算出可能です。今回利用するOWASP TOP10のテンプレートでは、ウェブACL=1個、ルール=10個となるため月額 $15となり、それにリクエスト料金が加算されます。
  • リクエスト
    • こちらは毎月確実に変動します。100 万ウェブリクエストあたり $0.6 です。仮に1PVを20リクエストだと仮定すると、月間PV500万のサイトで月額$60になります。
  • ※上記参考値は2017年10月時点の料金を元に計算しています。

実際のところどうなのか

• つらつらと書いてしまいましたが、弊社の導入実績から申し上げると「AWS WAFは事前検証を実施することで充分に適用可能」と考えております。セキュリティはどこまでいっても品質とコストのトレードオフの問題が付きまといます。大規模サイトではAWS WAFのコストメリットは品質にくらべて効きづらくなりますが、小・中規模サイトで事前検証ができる、つまりWebアプリケーションを自前で変更できる技術力さえあれば「ちょうどいい」選択肢になりえます。

AWSからOWASP TOP10(※) 2017年版をベースにしたAWS WAFのテンプレートが公開されています。以下URLにアクセスしてください。

https://aws.amazon.com/jp/about-aws/whats-new/2017/07/use-aws-waf-to-mitigate-owasps-top-10-web-application-vulnerabilities/

• ※OWASPとはセキュリティ向上を目的としたコミュニティ団体です。OWASP TOP10とは、OWASPが定義した、Webアプリケーションにおける代表的なセキュリティリスクを示したものです。

• OWASP TOP10 2017年版は2017年10月現在RC版となっているため内容が変更される可能性があります。

• ※AWSが提供するテンプレートには上記以外にもAWS WAF セキュリティオートメーションなどがありますが今回はあえて触れません。「AWS WAF セキュリティオートメーション」は、今回のテンプレートのOWASP TOP10とほぼ同等のテンプレートに加え、Lambdaを組合せた様々な機能がCloudFormationで展開されるリッチなテンプレートです。Lambdaコードの勉強用としても一見の価値があります。

下図の赤枠で囲ったところにCloudFormation用のテンプレートファイル(yml)のリンクがありますので、そこからファイルをダウンロードします。

• AWS WAFの構築はCloudFormationを利用します。構築用のIAMロールを事前に作成します。
• AWS のマネジメントコンソールにログインし、IAMメニューを開きます。 左メニューより「ロール」を選択し、CloudFormationを選択します。

• ここでは簡単のため AdministratorAccessポリシーを付与します。

• ロール名を入力し、「ロールの作成」を押下します。

AWS のマネジメントコンソールにログインし、CloudFormationメニューを開きます。 「スタックの作成」ボタンをクリックします。

• 「テンプレートをAmazon S3にアップロード」にチェックをつけ、さきほどダウンロードした owasp_10_base.ymlファイルを選択します。

• スタックの名前を入力します。(ここではスタック名を「waf-owasp」としています)
• その他の値は各ルールのパラメータを指定できますが、後からでも変更できるのでいったんデフォルトのままとし、画面下部の「次へ」ボタンを押下します。

• 2.にて作成したロールを「IAMロール」に指定し、「次へ」を押下します。

• 確認画面が表示されますので、「作成」ボタンを押下します。

• するとCloudFormationの画面に遷移し、スタックの作成が開始します。完了するまで待ちます。(おおよそ5分で完了します。完了するとステータスが「CREATE_COMPLETE」に切り替わります)

• まずはAWS WAFの設定を確認しましょう。左上の「サービス」メニューより「WAF & Shield」を選択します。
• AWS WAFの画面が表示されたら左メニューより「Web ACLs」を選択してください。
  • 初回は以下の画面に遷移する前にイントロページが表示されます。その場合は「Go to AWS WAF」ボタンを押下してください。

• 「Web ACLs」に今回テンプレートで作成した「generic-owasp-acl」が表示されていることを確認し名前をクリックします。

右側にあるタブの「Rules」をクリックします。すると下部にテンプレートで作成されたルール一覧が表示されていることを確認します。

• 以上でAWS WAFが出来上がりました。このあと必要になる作業は以下となります。
  • WAFのルールをカスタマイズする(本項では割愛)
  • ALBもしくはCloudFrontにWAFを関連づける(本項では割愛)

• 前編は以上です。後編では以下について説明していきます
  • AWS WAF 設定の理解
  • テンプレートで展開されるルールについて
  • テンプレートで提供されていないカテゴリ
• (2018/1/11更新)
  • 後編は下のリンクからどうぞ！
    • 【AWS WAF】テンプレートでお手軽にWAFを構築しよう！【後編】