AWS WAF（ウェブアプリケーションファイアウォール）を使う時の影響

by asano

AWSのWAFというウェブアプリケーションファイアウォールを利用する際の影響やトレードオフについて書きます。

https://aws.amazon.com/jp/waf/

なぜWAFを使いたいのか

アプリケーションを実装する際にはインジェクションやCSRFを始めとする様々な攻撃から守るようにしていますが、アプリに届く前に攻撃を検知・対応ができれば、より運用で安心度が高まります。

WAFがもたらす副作用

ウェブアプリケーションファイアウォールを通したいということは、間に何かフィルタが入るという形になります。 WAFはCloudFrontを介してフィルタをかけるので、キャッシュ目的でCloudFrontを使いたいわけではない場合に、アーキテクチャや運用が大げさになってしまう可能性もあります。

CloudFront

WAFではHTTPのヘッダー情報もチェックしてくれるのですが、WAFが依存しているCloudFrontがレスポンスヘッダー情報に値を追記してしまうなど、幾つかのサービス仕様があります。通信データの変更を加えたくない場合には、WAFが邪魔になる場合もあるかもれません。

CloudFrontやWAFの機能でエラーになった場合に表示されるエラーページに「generated by cloudfront (cloudfront) 」の文言が入ってしまいます。正常、異常にかかわらず、レスポンスヘッダに「cloudfront」の文字が入ってしまいます。使用しているミドルウェア情報などをユーザに見せたくない場合に困ってしまいます。

気をつけたい点

WAF

作成した制約に違反する場合、403のエラーを返します。 403のエラーページは、CloudFrontでカスタマイズでききます。

料金面の影響について

  • CloudFrontへ設定するSSLについて
    • 独自SSLを使う場合、クライアントがSNIをサポートしている必要があります。未対応のクライアントを使用する場合、専用 IP 独自 SSLオプションを使用する必要があり、毎月 600 USD （日割り）が必要になります。 https://aws.amazon.com/jp/cloudfront/custom-ssl-domains/

性能面の影響について

間に一つ何かを挟むということは、性能にも影響してきます。 気になるWAFでリクエストBodyをチェックする際のWAFの挙動は現時点では下記の通りです。

挙動

Bodyチェック設定をした場合は、リクエストはWAFがリクエストBodyを受け取りながら徐々にチェックをかけつつ、同時進行でELB側にリクエストを送り続けるようなものではなく、クライアントから送られてきたリクエストBodyをWAFの内部で一旦メモリ内に保持して、チェックをし、チェック完了後にELBへデータを送信します。

現状ではWAFは最初の 8KB のみを CloudFront から転送しチェックしており、チェック完了後、許可されたリクエストは継続して CloudFront 動作を続けます。

このサイズは変更不可能なものとなっており、8KB より大きな body データにつきましては現在 WAF でチェックすることができないというのが仕様のようです。

つまり、大きなBodyリクエストを送られてきた場合でも影響を受けず一定の処理時間で捌くことが可能ですが、チェックが完璧だとは言えないということになります。

最後に

WAFは非常に便利で強力なサービスですが、うまく付き合わないと逆にデメリット面が大きすぎたり、WAFを入れているから大丈夫だろうという姿勢でいると、思わぬところで穴がでてしまいます。

WAFではできないこともあるので、NginxやウェブアプリケーションでWAFの弱点を補いながら対策しつつ、WAFの費用対効果を考えて導入検討をするとよいと思います。