こんにちは、臼田です。

みなさん、サーバレスしてますか？(挨拶

先日AWS WAFに大きなアップデートがありました。これに伴いAWS WAFはv2となっていて、中身の仕組みがいろいろ変わっています。

[アップデート] AWS WAF向けAWS製のManaged Rulesが出ました

そのため、各セキュリティベンダーから提供されるマネージドルールも作り直されているみたいでまだv2でリリースされているマネージドルールは多くありません。

そんな中、日本のWAFベンダーであるCyber Security Cloud(CSC)さんからはv2対応のAWS WAFマネージドルールが2つ提供されています！

• Cyber Security Cloud Managed Rules for AWS WAF -HighSecurity OWASP Set-

• Cyber Security Cloud Managed Rules for AWS WAF -API Gateway/Serverless-

前者はこれまでも提供されていたものと同じような感じですが、注目すべきは後者！

＿人人人人人人人人人人人人人人＿
＞　-API Gateway/Serverless-　＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

AWS WAFがAPI Gatewayに対応して久しいですが、API Gateway用のマネージドルールが出てくるのは嬉しいです。個人的な主観ですが、API GatewayはRESTfulなAPIエンドポイントのため、ALBと比べると扱うフォーマットが限定的だったり、バックエンドにLambda等を利用するときにはサーバOSを意識することは少なかったり、つながる先もNoSQLになったりといろいろ変わる部分があります。これをALBと同じマネージドルールで守ってもある程度効果が出ると思いますが、既存のルールだとAPI Gatewayで使うには余分なルールもあると考えられるため、API Gatewayやサーバレスに最適化されたマネージドルールというのは良いものです。

また、CSCさんはマネージドルールを日本語でサポートしてくれる唯一のベンダーさんでもあります。心強い！

API Gatewayを使っている上でWAFを選択する際のベーシックな選択肢になるのではないでしょうか。

ルールの説明を見ると、下記のようなものをブロックするとあります。

• コードインジェクションテクニック（SQLi、NoSQLi、OScommandiなど）
• XML外部エンティティ攻撃
• サーバーサイドリクエストフォージェリ(SSRF)
• XSS(クロスサイトスクリプティング)
• ディレクトリトラバーサル
• 悪意のあるボットルールセット

悪意のあるボットのアクセスや様々な攻撃から守ってくれそうです。SSRFに対応したルールと明示されているマネージドルールも初めてだと思います。

というわけで早速使ってみましょう！なお、API Gatewayやそのバックエンドの作成はされている前提で進めます。

やってみた

AWS WAFの設定

まずはAWS WAFのコンソールにアクセスします。新しいコンソールにスイッチするリンクが出ていますのでこちらに切り替えます。

マネージドルールはまずAWS MarketplaceからSubscribeする必要があります。下記のように開くか、直接こちらを開きます。

Continue to Subscribeを押します。

購入画面に来るのでSubscribeを押します。ちなみに値段は月額$25 + 100万リクエスト毎に$1.2と非常に安いです。実際は月額も1時間単位で割られるので、とりあえず検証のためにSubscribeしても全然問題ありません！

Subscribeしたら下記リンク等で元の画面に戻ります。

元の画面でSubscribeされていることが確認できます。

続いてWeb ACLを作成します。Web ACLsの画面にアクセスしてAPI Gatewayの存在するリージョンを選択してCreate web ACLを押します。

Name等を適当に入力します。CloudWatch metric nameは自動的に補完されます。リソースタイプは先程選んだものになっていれば問題ありません。

webACLの作成に合わせてAPI Gatewayにアタッチすることが可能です。後からでも追加できますが今回はここから追加していきます。Add AWS resourcesを押します。

該当のリソースを選択してAddします。

追加されていることを確認してNextを押します。

続いてルールの追加画面です。Add rulesの中からAdd managed rule groupsを選択します。

先程Subscribeしたルールを選択します。選択するとcountで利用するか？というボタンも出てきますが、今回はBlockで利用したいためチェック入れずにAdd rulesで進みます。なお、CapacityはAWS WAF v2から出てきた概念で、これまでのwebACL毎にRule10個が上限という制約がなくなった代わりにRuleのCapacityが1500までという制約になりました。また、AWS自身が提供するマネージドルール(AMRs)もここでいっしょに選択でき合わせて利用できます。AMRs等の詳細は先程のブログをご確認ください。

Default actionはルールに引っかからなかったパケットを通すかどうかのルールです。マネージドルールではマッチしたらBlockされるので、最後に残ったパケットはAllowとします。Nextへ。

ルールの順序設定の画面です。今回は1つしかないのでそのままNextへ。

続いてルールのCloudWatch metricの名前を変更できます。特に変更する必要性がないのでNextへ。

確認画面でCreate web ACLを押して作成します。

これで作成完了です。

Blockしてみる

まずSSRFについて検証してみます。

$ curl -i https://xxxxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/test/?url=http://169.254.169.254/latest/meta-data/
HTTP/2 403
content-type: application/json
~省略~

{"message":"Forbidden"}

無事403が返ってきました。

続いてBotについても試してみます。それっぽいリクエストを作って送ってみます。

$ curl -i -H "User-Agent: *********" https://xxxxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/test/
HTTP/2 403
content-type: application/json
~省略~

{"message":"Forbidden"}

403で止めてくれました。

まとめ

新しくなったAWS WAF v2向けに、かつAPI Gateway / サーバレス向けに提供されたCyber Security Cloud Managed Rules for AWS WAF -API Gateway/Serverless-を検証しました。

API Gateway及びサーバレスを守る様々なルールが入っているので、とりあえずWAFを入れるという場合にまず選択肢に挙げていいと思います。

是非活用してみてください。