注目の記事

AWS WAFを完全に理解する ~WAFの基礎からv2の変更点まで~

AWS WAFを完全に理解したい人向けにまとめました。WAFとは、というところからまとめています。メインはv2となったことで変わったことについて書いています。目指せAWS WAFチョットデキル。
2020.03.04

こんにちは、臼田です。

皆さん、WAFWAFしてますか?(挨拶

今回はタイトル通りAWS WAFを完全に理解するための情報を全部詰め込んだブログです。長いです。

そもそもWAFってなんだっけ?という話から初めて「全部理解した」と言えるようになるまでをまとめています。直近AWS WAF v2がリリースされたため、この変更点を中心に機能の説明をします。

Developers.IOではWAFを扱った記事がたくさんあるので、細かいところはブログを引用します。いわゆる元気玉ブログです。

おさらい的な部分も多いので変更点が気になる方は適当に飛ばしてください。

そもそもWAFとは

AWS WAFの前にWAFの話をします。WAFはWeb Application Firewallの略でWebアプリケーションを保護するためのソリューションです。

一般的なWebアプリケーションに対する攻撃手法としてSQLインジェクションやXSS(クロスサイトスクリプティング)などがありますが、これらの脅威から保護します。(もっといろんな攻撃から保護することが多いですがここでは省略)

ソフトウェア、ハードウェア、サービスとして利用する形態などがあります。

ファイアウォールとありますが、純粋なファイアウォールと重複した役割(L3/L4の保護機能)を持っているわけではなくL7に対してのみ動作します。IDS/IPSとも役割が異なります。そのため、どれかが利用されていれば他のソリューションが必要ない、ということは全く無いです。そもそもファイアウォールやIDS/IPS、WAFがあるからセキュリティ上安全になるわけではなく、一部分を保護できるだけのため、根本的に保護対象のサーバやアプリケーションの脆弱性を管理することや、適切に運用することが必要ですので入れればOK、というものでもないことには注意が必要です。

WAFのわかりやすい概要はこの記事がいいです。なぜWebサイトのセキュリティ対策にWAFが必要なのか?理由を徹底解説 | セキュリティ対策 | CyberSecurityTIMES(上記図引用元)

正しくWAFを理解するには下記ドキュメントを参照してください。

Web Application Firewall 読本:IPA 独立行政法人 情報処理推進機構

AWS WAFとは

AWS WAFは文字通り、AWSが提供するWAFです。

利用形態

WAFの種類はいくつかありますが、AWS WAFは下記にインテグレートしてサービスとして利用します。

  • CloudFront
  • ALB
  • API Gateway

AWS WAF以外のWAF

AWS上で利用できるWAFとしては元々、下記のようなベンダーのマーケットプレイスから購入してEC2上で動作させるものもあります。

  • F5
  • Imperva
  • Barracuda
  • 等々

AWS WAFのメリット/デメリット

サービスとして利用できるAWS WAFとその他のWAFでは下記のような違いがあります。

  • いいこと
    • 簡単なデプロイとインテグレート
    • 圧倒的なスケーラビリティ
    • 基盤が管理されているマネージドサービス
    • 従量課金でコスパがいい
    • 簡単なログ出力とAWSサービス連携によるログ調査環境
    • セキュリティベンダーのマネージドルール
  • できないこと
    • きめ細やかなルールのチューニング
    • すべてのパケットログ取得
    • 戻りパケットのチェックやフィルター

EC2上に構築するWAFは特性上、直接ネットワークに挟むとボトルネックになることがありますが、AWS WAFでは上記サービスにインテグレートされてスケールするため柔軟性に優れています。基盤もAWSが管理しているため、死活監視やサーバ自体のメンテナンス、ファームウェアの管理等が不要で非常に簡単に利用できます。

一方で細かいことはできません。高度なセキュリティ要件がある場合にはセキュリティベンダーの提供するWAFも利用する必要があるでしょう。このあたりは要件によって使い分けることになります。併用する選択肢もあります。

AWS WAFについてよく理解するには下記が参考になります。v1のWAFについての内容ですが概ね同じであるため問題ありません。

マネージドルールというセキュリティベンダーが提供しているルールを簡単に利用できることもメリットです。これらのルールは、従来セキュリティの知識がないと難しいAWS WAFのルールの運用をセキュリティベンダーが代わりにやってくれる大変便利な機能です。

AWS WAFの用語

  • WebACL
    • 1つのWAFの設定の塊
    • CloudFront / ALB / API Gatewayに割り当てる単位
    • 1つのリソースに対して1つのWebACLのみ割り当て可能
    • 複数のリソースに対して同じWebACLを割り当て可能
    • 複数のルール/ルールグループを内包する
  • ルール
    • リクエストに対する条件のまとまり
    • 例えば指定したIPにマッチするか、特定のクエリストリングがあるか等
  • ルールグループ
    • ルールをまとめたもの
    • 事前に定義可能
  • アクション
    • リクエストをルールに照らし合わせた結果をどう扱うかの設定
    • ALLOW / BLOCK / COUNTがある
    • ルール毎にアクションがあり、すべてのルールに当たらなければWebACLに設定されたDefault Actionに沿って処理される

AWS WAFの位置づけとAWSセキュリティ

WAFを導入するからにはセキュリティの強化が目的だと思います。その前提となるAWSセキュリティもサラッとおさらいしましょう。

AWSのセキュリティを考える上での大前提は責任共有モデル(下図引用元)です。

Shared_Responsibility_Model_V2_JP

簡単に言うとにAWSが管理する部分はAWSが責任を持って、その上のOS/アプリやAWS上の設定等はお客様が責任を持つというものです。わかりやすく明確な分解点です。サービスによってAWSがどこまで面倒を見ているかは異なります。

AWS WAFはお客様が作るアプリケーションの前に置くことによって効果を発揮しますが、当然アプリケーションの動作するEC2のセキュリティを考えたときには、Security Groupによるアクセス制御やOS/ミドル/アプリケーションの脆弱性診断/管理(パッチマネジメント)なども行う必要があります。

AWS WAFを導入するだけですべてが守れるわけではないことはもちろん、それぞれのコンポーネント・レイヤーによって利用すべきサービス、注意する設定などは変わりますので意識しましょう。

全体としてどう考えていくかは下記ブログがわかりやすいと思います。

AWS WAFを利用する前にはもちろん、CloudTrail / AWS Config / GuardDutyなどの基本的なサービスが有効化されていることも確認しましょう。AWSセキュリティベストプラクティスについて理解するには下記が参考になります。

AWS WAF v2の変更点

さて、本題です。2019年末頃に新機能AWSマネージドルールと共にAWS WAFが新しいバージョン(v2)になりました。

AWS WAF向けのAWSマネージドルールの発表| AWSニュースブログ

ここまでv2と書いていますが、現状ではAWS WAFと記述するだけで新しいAWS WAFであると表現され、書き分ける場合には New AWS WAFなどと書かれます。古い方を AWS WAF Classicと書くことが多いです。この記事ではわかりやすいように新しい方をv2と書いてます。

なぜv2と呼んでいるかですが、APIがv2となっているためです。

大きく下記のような変更点があります。

  • v1とは別リソース/別API/別コンソール
  • キャパシティユニット導入
  • AWS マネージドルール対応
  • ルールの記述方法の変更

それでは変更点を見ていきましょう。

別リソース/別API/別コンソール

先程APIがv2となったと書きましたが、古いAPIはそのまま生きています。というわけでv1とv2は共存しています。

コンソール画面を見ていきます。

新しいAWS WAFのコンソールですが、左側のメニューにSwitch to AWS WAF Classicと書かれています。これを押すと古いコンソールに変わります。

ちなみにURLもhttps://console.aws.amazon.com/wafv2となっています。

既存でWAFのリソースがある場合には切り替えて見るとわかりますが、v2になるとあるはずのリソースが表示されなくなります。これは、v1とv2でリソースが異なるためです。

v1のリソースは引き続きv1のコンソール、v1のAPIで管理し、v2とは別物の扱いになります。

ちなみに現状、v1からv2への移行方法は「手動でがんばってね☆ミ」という感じで公式ドキュメントに書かれていました。移行するメリットはなくもないですが、現状ではそこまで頑張らなくてもいいと思います。

キャパシティユニット導入

これまでv1では、ルールが10個までしか登録できませんでした。

ルールとは、WAFの動作する様々な条件の定義で、例えば下記のような条件で1つのルールとなりました。

  • 指定したIPからのアクセスを拒否する
  • XSSとなるような文字列を拒否する
  • 特定のIPのみ/adminパスへのアクセスを許可する
  • 過剰なリクエストがあるIPを拒否する

条件を付け足していくとどうしても10個のルールではできることに限界がありました。

v2では10個という制約の代わりに、ルールの数ではなく重みを評価するようになりました。それがキャパシティユニットです。

ルールの内容によってルール毎にキャパシティが算出され、1つのWebACLに1500Web ACL Capacity Unit (WCU)までルールを組み込むことが可能になりました。下図のように1ずつ重み付けされます。

設定した内容でどの程度のキャパシティとなるかはドキュメントにありますが、殆どの場合1500WCUまで使用することは無いでしょう。

AWS マネージドルール

v1の時は各サードパーティのセキュリティベンダーがマネージドルールを提供していましたが、AWSからも純正のマネージドルールがリリースされました。

複数のマネージドルールがあります。

  • Baseline Rule Groups: 一般的な脅威からの一般的な保護
    • Core Rule Set (CRS): 一般的なルール。OWASPやCVEに記載されているもの等が含まれている。
    • Admin Protection: 公開されている管理ページの保護。
    • Known Bad Inputs: 脆弱性を発見/悪用するリクエストの検知。
  • Use-Case Specific Rule Groups: 用途別の保護
    • SQL Database: SQLインジェクション等のSQLデータベースに対する攻撃からの保護
    • LINUX operating system: LFIなどLinuxOSへの攻撃の保護。POSIXOSルールと合わせて利用。
    • POSIX Operating System: Linux、FreeBSD等POSIX OSの保護。
    • Windows Operating System: Windows OSの保護。
    • PHP Application: PHPアプリの保護。
    • WordPress Application: WordPress固有の脆弱性に対する攻撃の保護。
  • IP Reputation Rule Groups: IP評価ルール。
    • Amazon IP Reputation: AWSの持つ悪意あるボット等のIPアドレスからの保護。

それぞれ25〜700のキャパシティユニットが設定されており、併用することが可能です。

私の所感としては、基本CoreとIP Reputationとその他必要なルールを組み合わせる感じに利用する方向で良さそうです。サードパーティのマネージドルールを使う場合もIP Reputationは併用して良さそうです。

ルールの記述方法の変更

v1ではルールの中には複数のコンディションが含まれていました。

コンディションとは「パスが/admin」とか「このIP」とかの条件にあたります。複数のコンディションを組み合わせて1つのルールとしていました。

v2ではコンディションからステートメントに変わり、条件の記述の方法が変わりました。

一番の変更点はAND/OR/NOTと共にステートメントを組み合わせることができるようになりました。コンディションはANDでしか記述できなかったため表現の幅が大幅にアップしました。組み合わせてネストすることも可能です。

そして、ステートメントの組み合わせはJSONで記述され、import/exportできるようになりました。

これまでルールの中身を変更するためにはたくさんのコンディションを操作するAPIが必要でしたが、JSONを用いることで簡単に設定を流用することができます。

実際のルール設定画面は下記のようになっています。ビジュアルエディタもありますが、JSONエディタに切り替えて細かく設定したり、既存の設定を持ってきたりできます。

この図ではANDステートメントの中にXSSのステートメントと、特定のIPのNOTステートメントを入れています。このステートメントは管理IP以外のIPからのXSSをマッチします。

WAF v2をどう使っていくか

変わったところ、変わってないところ含めてどう使っていくかという話をします。

v1とv2どちらを使うべきか

現状特に機能的な問題もなく、いい事づくしなので何もなければv2を使いましょう。

ただ、無理にv1から移行する必要はありません。

基本的な使い方

v1とは基本的な使い方は変わりません。

まず、前述の通り他のセキュリティについても意識しつつ、WAFは完全に攻撃を防げるものでは無いので特性を理解して使うことです。

AWS WFAを利用する場合にはログを有効化し、検知状況を常に監視します。

ログの取得や確認方法は下記が参考になります。

導入してしばらくはCountモードとして動作させ、誤検知がないか等をログで確認し、問題ないと判断したらBlockにするといいです。

入れ子のルールはJSONで

ルールが柔軟に記述できるようになり、ネストすることも可能になりましたが、マネジメントコンソール上でポチポチするだけだと細かく入れ子になるルールは設定できません。

そういった場合にはJSONで直接記述する必要があります。

マネージドルールを活用

AWSマネージドルール含めマネージドルールを活用しましょう。

お手軽なのはCSCのOWASP Top 10対応ルールが全部盛りなので、これを利用することを推奨します。

API Gateway用もあります。

CSCルールの場合には、同じくCSC社提供のWafCharmを併用するとセキュリティが強化されつつ環境に合わせた調整が簡単に行なえます。

まとめ

AWS WAFについてv2での違いを中心に説明しました。これで完全に理解できると思います。

理解したら実践あるのみ。触り始めて、きっと「AWS WAFなんもわからん」となるでしょう。

とくにステートメントをJSONで記述するところはいい感じのドキュメントがないため手探りになると思います。

コンソール上のValidateボタンを駆使して頑張りましょう。

AndStatementの中はStatementsがあり、その中はlistになっていることや、NotStatementの中はStatement(sはない)でlistじゃなく単体のStatementが入ることが理解できれば割と楽に理解できる…はずです。

とにかくまずはやってみましょう。