話題のクラウドセキュリティサービス AWS WAFを触ってみた。 | mediba Creator × Engineer Blog

話題のクラウドセキュリティサービス AWS WAFを触ってみた。

はじめに

mediba インフラストラクチャー部の杉山です。 AWS WAFについて軽く触れてみたので簡単なレビューを行いたいと思います。さらに攻撃や防御の手法なども踏まえ、WAFが生まれた背景についても触れてみます。

攻撃手法

便利なインターネットですが残念ながらこの界隈には悪意ある人がたくさんいて、 黎明期より彼らから身を守る技術が培われてきました。まずはどんな攻撃方法があるのかを列挙します。

  • XSS(クロスサイトスクリプティング)
  • フォースフル(強制的)ブラウジング
  • インジェクション(SQL、メタキャラ、OSコマンド)
  • パラメータ改ざん
  • HTTPレスポンス分割
  • セッション管理情報改ざん
  • バッファオーバーフロー
  • バックドア、デバッグオプション
  • エラーコード参照
  • ユニコード及びURLの符号化による検知回避

詳しい説明は避けますが、直接機密情報を閲覧、改ざんするもの、誤動作でそれらを実行できるようするものがあります。エラーコードですら攻撃者にぜい弱性を推測される情報となったりします。

防衛手段

上記攻撃から身を守る術をまとめます。と言っても選択肢は多くなく、地道にコードや実行ファイルの修正を行うしかありません。オープンソースなコードであればサードパーティや有志が作ったセキュリティパッチを適用することで回避できますが公的な意味ではコードの修正と同義です。

すべてのぜい弱性に対してリアルタイムに対応することは出来ないので多くは下記のようなプロダクトを使います。

  • Firewall
  • IPS
  • WAF
  • アンチウイルス/マルウェアソフト

Firewall, IPS, WAFの違い

アンチウイルス/マルウェアソフトを除けばどれも似たような機能を持っていますが違いを説明します。

Firewall

通過するリクエストの送信元や送信先のIPアドレス、プロトコルを見てリクエストを制御します。古くからある技術ですが、アプリケーション層の情報を見ることはできない為、XSSやSQLインジェクション等の攻撃を防ぐことはできません。

IPS

Firewallの穴を埋める技術としてIPSが生まれました。IPSは定義された検出パターンに基づいて様々な攻撃を検査することができます。しかし、これでもパラメータやセッション管理情報の改ざんなどWebアプリケーションに特化した攻撃を防ぎきることができません。

WAF

そこでWAFの登場です。WAFは、IPSと非常に動きが似ていますが、Webアプリケーションの動作を理解しているため、より細かい防御が可能なことと、SSL通信の中身を見ることができるのでSSL通信に隠ぺいされた攻撃も防ぐことができます。

そんなWAFも先日、ついにAWSで利用できるようになりました。少し触ってみましたのでその情報をまとめます。

AWS WAFの概念

AWS WAFは[condition], [rule], [ACL]という3つの概念があります。conditionが最小概念で、そのうちのいくつかがまとまってruleが構成され、出来上がったruleをどう処理するかをACLで定義します。最小概念であるconditionから説明します。

condition

条件です。「このIPアドレスからの接続」, 「User-Agentに○○が含まれている」などの条件を指定します。

rule

複数のconditionをand条件で指定します。上記conditonで例えれば「このIPアドレスからの接続」且つ「User-Agentに○○が含まれている」というようなルールを作成できます。

ACL

作ったruleに対してどういう処理をするのかを定義します。[Allow], [Block]. [Count]が指定できます。またruleにマッチしなかったリクエストをどうするのか(全許可か全拒否の二択)を指定します。

作成例

[medibaのGatewayアドレス]、且つ[ブラウザがChrome]からの接続のみ許可するというACLを作ってみましょう。

AWSのサービス一覧から[WAF]を選択し、[Get Started]をクリックします。

ウィザードに従い、まずはACLを作成することになります。適当なACL名を入力して[Next]をクリックします。

conditionの作成は一旦スキップします。何もせずに[Next]をクリックしましょう。次にruleを作成します。[Create rule]をクリックすると以下の画面が表示されますので適当なrule名を入力して[Create]します。

あとでruleの詳細を設定しますが、ruleにマッチしたリクエストは許可(Allow)し、マッチしないものは拒否(Block all requests that don’t match any rules)します。

[Confirm and create]をクリックします。

conditionを設定します。まずはIPアドレスから。[IP Addresses]をクリックし、[Create Condition]をクリックします。

適当な名称を入力してIPアドレスを指定し、[Create]をクリックします。medibaのゲートウェイアドレスを指定するわけですが、この画像の情報はダミーです。

次に[ブラウザがChrome]という条件を定義します。[String matching]をクリックし、[Create condition]をクリックします。

適当な名称を指定し、上から順に、[Header], [User-Agent], [Contains], [None], [Chrome]を指定します。その後[Add anoher filter]をクリックし、[Create]をクリックします。

ruleにconditionを組み込みます。[Rules]を選択、冒頭で作成したRuleをクリックし、[Edit rule]をクリックします。

先ほど設定したconditionを以下のように組み合わせ、[Update]をクリックします。

これでACLが完成しました。CloudFrontに組み込んでみましょう。なお、S3とCloudFrontの設定は割愛します。

条件を満たさない状態でアクセスすると以下のようにリクエストがブロックされたことが分かります。

AWS WAFを触ってみて

WAFはCloudFrontのオプションとして動くので、セキュリティグループとは違います。セキュリティグループはEC2上で動くソフトウェアFWという位置づけで、FWとWAFの違いは上記で述べた通りです。

AWS WAFの機能は割とシンプルなので、少し触ればすぐに理解できるようになると思います。オンプレミスのWAFは高価なので、AWSのマネージメントコンソールから気軽に触れるようになったというのは、取っ掛かりとしては非常に良いと思います。

ただ、その分細かい制御はできない(特にマッチ/アンマッチしたルールをリダイレクトできないことは確認済み)ので、現段階では、WAFの機能を最大限に利用したいならサードパーティ製品を考えた方が良いかもしれません。

AWSは常に進化しているので、利用者が増えればその意見を反映し、いずれその性能差は埋まっていくのではないかと思いますのでそこに期待です。

セキュリティのトレンド

本検証の過程で、とあるセキュリティベンダに以下のようなことを伺いました。

  • マルウェアは年々増加の一途を辿り、マルウェア作成ツールまで出て、知見のない人でも簡単に作れる
  • 昔はWindows主流だったが、今ではLinuxが主流(個人を狙うよりもある程度の規模のサイトを狙った方が影響範囲が大きく、攻撃者にとっては都合が良い)

なので、冒頭でも触れましたが、PCでは主流のアンチウイルス/マルウェアソフトを現在はサーバ機にも入れることがトレンドになりつつあるらしいです。WAFすら通り越してしまった攻撃を本当の瀬戸際で防ぐというわけですね。こちらはオンプレに限らずAWS(のEC2)にも対応しているとのこと。会員情報を格納しているサイトや決済サイトでは必須になりつつあるのかもしれません。

おわりに

Web業界はスピード重視で攻めの姿勢が非常に重要ですが、脇をつつかれて失速しないように、守りの技術も磨いていかなければなりません。どちらも同じくらい大事ですがそのバランスも大事です。今後も新しい情報や技術があればキャッチアップして公開できればと考えております。

よろしくお願いします。