STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

WAFを活用する上で入れておきたいファイアウォールのルール定義

プロダクト基盤本部の藤原です。

本エントリではWAF(Web Application Firewall)を活用していく上で、最初に導入をお勧めするファイアウォールルールを解説します。

WAFとは

WAF(Web Application Firewall)とはWebアプリケーションに特化したファイアウォールです。 HTTPリクエストのヘッダやボディの内容から不審なリクエストを判別し、アクセスをブロックすることを目的としています(図1)。

図1 WAFの役割

WAFの活用を通じて実現したいこと

WAFの活用を通じて実現したいことはなんでしょうか。 悪意のあるリクエストや不審なリクエストからアプリケーションを保護することでしょう。

不審なリクエストとしては、宛先が合っていないリクエスト(HTTPのホストヘッダを誤っている)1や、スクリプトキディ的なものから攻撃対象を精緻に分析したものまでさまざまな程度のものがあります(図2)。

図2 さまざまな程度の不審なリクエストや悪意のあるリクエス

図2でとくにわたしたちが対応すべきは、最後の入念に練り込まれた悪意あるアクセスです。 このようなアクセスを詳細に分析した上で、さまざまな対策を講じたいはずです。

余計なノイズをフィルタする

図2のスクリプトキディ的なものについては、WAFベンダーの提供しているルールや、OSSとして公開されているルール2でほとんど対応が可能です。 単純なディレクトリトラバーサルSQLインジェクション、OSコマンドインジェクションを試みるものは外部から提供されるルールで対応が可能です。

そのようなリクエストをアプリケーションに到達させない目的であればこのようなルールのみで十分です。

しかし、このようなスクリプトキディに起因するログレコードは、より深く分析したいログレコード、つまり対象を精緻に分析した攻撃意図のあるリクエストのログレコードを抽出する際にノイズになってしまいます。 効率的な分析の実現には、対象のレコードのみを抽出しやすいようにすることが重要です。

たとえば、スクリプトキディからのリクエストとして特定のWebアプリケーション3を対象にSQLインジェクションを試みるものがあります。 このようなリクエストは提供しているサービスと全く関係ないものです。実質的なリスクは低いと言えるでしょう。

サービスを分析した上での攻撃意図がみえるリクエストはSQLインジェクション試行疑いとしてブロックした上で、より詳細な分析ができるようにしておきたいはずです(図3)。

図3 ブロックしたリクエストの内訳

そこで、提供しているサービスと関係のないリクエストについては、より簡易な別のルールでブロックして分析対象から除外しやすいようにした方が良いでしょう。 リクエストクエリやパス、リクエストボディの内容を正規表現マッチングなどで検査するよりも単純なルールでブロックすることを考えてみます。

ここでポイントとなってくるのが、図2の宛先誤りです。 スクリプトキディのようにあまり対象を調査せず無差別に攻撃している場合、リクエストの宛先(ここではHTTPリクエストのホストヘッダ)が適切に設定されていないことがほとんどです。

よって、HTTPリクエストのホストヘッダが正しい値を指していない場合はブロックするルールを追加するだけで、ログを分析する際のノイズの大部分は排除できます。

具体的な設定例(AWS WAFの場合)

AWS WAFを例に示します(図4)。 HTTPリクエストのホスト(host)ヘッダの値がALBまたはCloudFrontディストリビューションに割り当てているFQDNの値でなければブロックするようにしています。

図4 AWS WAFでのホストヘッダの値誤りをブロックするルールの例

このような非常にシンプルなルールでWAFのログに含まれるノイズの多くを容易に除外できるようになります。

まとめ

設定内容としては単純ですが、本来対応すべき不審なアクセスの分析などの後段の作業を効率化するには、いかにしてノイズを除外するかが重要です。

そのための第一歩としてホストヘッダを使ったブロックは有効です。 ぜひWAFでのホストヘッダを使ったアクセスのブロックを検討してみてください4


  1. ハニーポットを運用したことのある方ならわかるかもしれませんが、アクセス元のDNS設定の誤りに起因するものなのか、想定している以上にホスト名が間違っているリクエストが届きます。
  2. OWASPが配布しているModSecurity Core Rule Setなどです。
  3. 著名なOSS CMSを対象としたものなど
  4. ただしWAFのみではなく、Webサーバーの設定や、AWS利用時はALBのリスナーなども含めて多層防御的な観点は忘れないようにしましょう