AWS WAFを触ってみて

はじめに

普段別製品のWAFの画面を日々触っているのですが、最近AWSを触る機会が増えてきました。
その中でふと、AWSの中でWAFセットアップしたらどんな感じなのか気になったので、今更ですが実際にAWS WAFを見よう見まねで組んでみましょうという記事です。

やりたいこと

• 社内のWebサイトを自分で防御したい
• お手軽にサクッとWAFを立ち上げたい
• それでいて誤検知もなくて防御もイケてる感じにしたい

WAFルールどんなものがあるか

まずはともあれAWS WAFで用意されているマネージドルールどのようなものがあるかです。
お任せでバーッてチェックを入れれば全部防御してくれることを期待。

WAFの画面とにらめっこするとこんなの出てきました。
以下は僕のとても雑な理解です。

• AWS-AWSManagedRulesCommonRuleSet
  • XSS、SSRF、ローカルファイルインクルージョンなどWebへの基本的なブロック
• AWS-AWSManagedRulesAdminProtectionRuleSet
  • よくあるWeb管理者画面へのURLアクセスをブロック
• AWS-AWSManagedRulesKnownBadInputsRuleSet
  • 特に注意すべき脆弱性のブロック。パッと見えたのはLog4JとJavaデシリアライズ
• AWS-AWSManagedRulesSQLiRuleSet
  • SQLインジェクションへのブロック
• AWS-AWSManagedRulesWordPressRuleSet
  • Wordpressへの攻撃のブロック
• AWS-AWSManagedRulesPHPRuleSet
  • PHPへの攻撃のブロック
• AWS-AWSManagedRulesLinuxRuleSet
  • こっちにもローカルファイルインクルージョンがある。Linux特有のファイルパス対策か
• AWS-AWSManagedRulesUnixRuleSet
  • UNIXというかこれはShellへのコマンドインジェクション対策っぽい
• AWS-AWSManagedRulesWindowsRuleSet
  • WindowsのDOSコマンド、Powershellへのコマンドインジェクション対策
• AWS-AWSManagedRulesAmazonIpReputationList
  • AWSが怪しいと思うアクセス元IPアドレスをブロック
• AWS-AWSManagedRulesAnonymousIpList
  • AWS、GCP、Azureなどの各種クラウドなど一般ユーザが使わなさそうなIPアドレスをブロック

よくあるWebサーバならある程度はこれで防御してくれるのでしょうか。
これらはFreeのルールたちで他にBotや詐欺対策、AWS公式以外のMarketplaceからのサードパーティー製のマネージドルールなどありました。

チューニング方針

なんとなくルールがわかったのでWAFでどのように守るか考えましょう。
頭に思い浮かんだこととしては以下です。

• 怪しいアクセス元は悪さするとわかりきっているので、IPList系は最初に優先してブロック
• 攻撃頻度高そうなものから優先度上げてブロック。CommonRuleSet、AdminProtectionRuleSet、KnownBadInputsRuleSet、SQLiRuleSetあたりか
• その後に個別の環境用のルール(WordPress、PHP、Linux、Unix、Windows)でブロックする
• IPList系は最初からブロック設定して、それ以外の各脆弱性RuleSetは誤検知を判断するため最初はCount設定
• もし誤検知があったらラベル機能を使って、特定のURLパスのみを除外するルールを作る(URLパス以外で除外条件作ると運用が破綻しそう)

テスト環境

というわけでテスト環境です。
といっても以下のようにELBとEC2を建てて、EC2からWebサーバ立ち上げるだけです。
(一応1枚ペラのHTMLファイルは格納しました)

ELBにWAFのACLを紐づけて外からのパケットを待ってみましょう。

何が検知されるか

Sampled requestsの画面を眺めていましたが、どうやらWebサーバを公開するだけでも手当たり次第に攻撃が来るようです。
気づいたことは以下。

• 攻撃はローカルファイルインクルージョンが大半
  適当に何かの設定ファイル、隠しファイルが覗けないかやみくもにアクセスしているようです。
• マネージドルールの攻撃取りこぼしが目立つ
  ローカルファイルインクルージョンに対応するのはCommonRuleSet、AdminProtectionRuleSet、LinuxRuleSetあたりかと思いますが、試しにツールで脆弱性スキャンかけたら結構な数がブロックせずすり抜けていました。本番で使いたいのであればルールを自作していろんなパスのローカルファイルインクルージョンを自分でブロックする必要あり。
• AnonymousIpListはほんとにAWSのIPアドレスをブロックしている
  攻撃者はAWSなどで一時的に攻撃元立ち上げると思うのでそりゃそうなんですが、本番でインターネット越しに何かのシステム同士連携させたい場合は除外が必要。

結局使えるのか

思ったよりチューニングに考慮点が多そう。
特にローカルファイルインクルージョンなどの取りこぼしが結構あったこと。
それ以外の攻撃手法に対してもそこまで精度高くないと推測すると、実際に使用するには以下も考慮しないといけなさそうです。

• ローカルファイルインクルージョンと、あと多分SQLインジェクションもチューニングが必要
  運用中に定期的に誰がどんなリクエストしてきたかを確認し、該当の文字列(URLパスまたはSQL文のキーワード)を次々ブロックするルールを作成することになる。
• 製品固有の脆弱性についてもそんなにブロックしてくれなさそう
  今回は検証してないですが上に書いたようにLog4JとJavaデシリアライズ、PHP、Wordpress関連のみがブロック対象な気がします。他の製品については別で考慮が必要、例えばApache、Nginx、Ruby on Rails、Node.jsなどなど。。。

APIを公開したりWebサイトが動的ページだったりすると別製品のWAF、またはMarketplaceからのサードパーティー製のマネージドルールがいい気がします。
このサードパーティー製のルールってどのくらいブロックしてくれるんですかね？

この辺は引き続き調査してみようかなと思ってます。

現時点での結論

今回はAmazon公式のマネージドルールを試してみましたが、おそらくサーバ1台程度で済む小規模のWebサイトを防御する用途なのかな～って感じました。加えてサーバ側のセキュリティ更新は常に最新にしておく(できる)ことが前提。

今回はここまでにします。
それではまた次の機会にお会いしましょう～