AWS WAFのマネージドルールを試す

初めに

こんにちは。CYBIRDエンジニア Advent Calendar 13日目の@daisuke-senmyouです。12日目は@yurika_fukaiさんの【恐怖】サイバードの企画職の実態でした。『Planter』導入後、企画職のメンバーが「トピックブランチをマスターにマージましたー」とか「あーコンフリクトした。少々お待ち下さい。」とかいう会話をしいてるのを聞いて自分の専門外のことも積極的に取り組む姿にいたく感動しておりました。エンジニアも負けてられませんね！

AWS WAFとこれまでの課題

AWSが提供するWAFです。
従来のアプライアンス製品はもちろん、クラウド型WAFと比較しても格安で導入できる画期的なサービスでしたが、大きな課題がありました。WAFは一定のルールに基いてリクエストを許可するか拒否するか判定しますが、AWS WAFではそのルールのほとんどを自分で定義しなければいけないという点です。
WAFの肝となるのはこのルール（シグネチャ）であり、さらに一度ルールを定義したらそれでおしまいではありません。日々進化する新たな攻撃手法に対して、ルールも日々更新していく必要があります。これを適切に定義し、また更新し続けることは高い専門的知識と大きな運用コストが必要でした。そこで登場したのがAWS WAFのマネージドルールです。AWS re:Invent 2017 で発表された新サービスです。

マネージドルールの設定手順

すでに良いレポートがあるので手順は割愛します。ただし今回はWordPressではなくOWASP TOP10に対する防御を試したいと思います。マーケットプレイスで購入するマネージドルールもFortinet Managed Rules for AWS WAF - Complete OWASP Top 10というものを試します。出品者のFortinet社はセキュリティ関連製品を多数提供している企業です。

攻撃対象サイト

この手の検証をする際には脆弱性を盛り込んだ自作の検証用サイトを利用することが多いのですが、OWASP Juice Shopというのが面白そうだったので使ってみたいと思います。こちらもすでに良いレポートがあります。

検査ツール

@pakchee さんが5日目の投稿で紹介している通り、弊社で利用しているVEXを使いWAF設定前後の脆弱性の検出を比較していきます。VEXでは様々な脆弱性が検出できるのですが、今回はわかりやすいSQLインジェクションとクロスサイトスクリプティング（XSS）について注目してみます。

WAFなしの検査結果

「判定数」の部分が検出されたカテゴリごとの脆弱性の件数です。詳細を見ていくと、例えば以下は商品の検索機能でXSSが検出された例です。危険度は上から２番目の"Medium"です。

これはAPIのレスポンスとしてJSONが表示されていますが、同様のリクエストをフォームに対して行うとダイアログが表示されました。XSSの脆弱性が確認できます。

この他にもSQLインジェクションが３箇所で検出されていました。うち１箇所はログインフォームで、以下の様に入力（パスワードはなんでも良い）すると実際にログインできてしまいました。

WAFありの検査結果

AWS WAFの管理コンソールでは、WAFで許可もしくは拒否された件数のグラフが表示されます。

こちらはXSSの攻撃をブロックしたというログが表示されています。

Cloud Watch でもグラフが確認できます。

VEXでの検査結果です。単純に件数だけの判断はできませんが、全体的に減少しているのが分かります。

SQLインジェクションの検出数が9件から6件に減っています。ログイン画面での検出がなくなりました。先程と同じ入力をしてみるとCloudFrontからのエラーメッセージが表示されました。

XSSも36件から7件に減っています。さらに詳細を見ると先程と脆弱性の内容が変わっており、危険度がMediumから一番下の備考レベルに下がりました。

その他の結果

• 特定条件で表示されていたスタックトレースを含むエラー画面が表示されなくなった。
• 今回の攻撃対象には該当しなかったが、Struts2 の脆弱性に対する攻撃ブロックのログが多数見られた。
• WAFを設定した際、お問合わせの投稿完了メッセージが表示されなくなった（WAFの誤検知か？）。

注意点

AWS WAF は CloudFront もしくは ALB に設定することができ、今回は CloudFront に設定しました。CloudFront の性質上、WAF の設定も伝搬に少し時間が掛かります。今回試した際は5分程度掛かったようです。Cloud Watch などで設定が反映されている事を確認してから検証する必要があるのでご注意下さい。

まとめ

マネージドルールを適用するだけである程度の攻撃は防げることが分かりましたが、はたして防げなかった攻撃もありました。正論を語ると、やはり脆弱性はアプリケーション側で根本的に対応し、WAF はもしもの時のセーフティーネット程度にしておくのが良さそうです。
しかし本格的な WAF の導入に踏み切れずにいるチームには適したサービスではないでしょうか。攻撃の痕跡も可視化されるので、「ほら、こんなに攻撃されているんですよ。もっとセキュリティに力入れましょうよ！」という予算取りの材料にも良いのではないでしょうか。

最後に

今後やりたいこととしてはCIの中にセキュリティ検査を組み込むというものです。VEXもJenkins連携機能が提供され技術的な条件は揃ってきているのですが、検査で長時間にわたりサーバーに高負荷を掛けてしまったり、検査用のデータが大量に投入されてしまうなどの課題がありなかなか実現できていません。来年こそは！
さて、CYBIRD エンジニア Advent Calendar 明日は、@sakamoto_kojiさんの「Action on Google(Dialogflow)」です。@sakamoto_kojiさんの部署では最近 「なみある？」が「Google アシスタント」に対応してそれに関連する記事のようです。楽しみですね！