WafCharm for Google Cloudを試してみた

# はじめに

先週、WafCharm for Google Cloudがリリースされました！
Cloud Armorのポリシーにルールを自動で追加してくれます。
こんな感じ。

![Screenshot at Nov 29 16-36-43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/dd57cc1c-4933-4005-46c2-5abb8b312ce5.png)

設定方法は公式サイトに細かく書いてくれています。
https://www.wafcharm.com/blog/gcp-how-to-get-started-with-wafcharm-jp/

ただ、Cloud Armor自体を初めて触る方などのライト層向けのGoogle Cloud設定の補足や、
自分自身がミスしていた点、ユーザー側でできるデバッグの方法などを共有しておきたいと思います。

# Google Cloud側での設定

## 今回の構成
一応、構成図を。
ただ、バックエンドがなんであろうと差異はないと思ってます。

![Screenshot at Nov 29 18-26-23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/4fc5e071-0c70-a36e-afa2-9527dfb867f5.png)


## バックエンドサービスのログを有効に
予め、有効化しましょう。

![Screenshot at Nov 29 16-55-48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/121a3312-e352-6e08-fa77-df7399f826a5.png)

こうすることで、ロードバランサーの通信内容を可視化することができます。
本題から逸れますが、ログを眺めていると、ロードバランサーに割り当てたFQDN指定でのアクセス、IPアドレス直指定でのアクセスが確認できました。
その中に、一部、"ww.xx.yy.zz.bc.googleusercontent.com" のようなFQDNアクセスがありました。これは、Google CloudサービスにアサインしたIPアドレス（ここではロードバランサーのIPアドレス）の逆引きとなるようです。気になる方は実際にご自身のGoogle CloudリソースのIPアドレスで確認してみましょう。

```
$ dig +short  -x xx.xx.xx.xx
```

## ポリシーTypeを間違えない
僕は今回、ここでしくじりました。
Cloud Armorのポリシーには、「Backend security policy」と「Edge security policy」の２種類があります。
今回、誤って「Edge security policy」にしてしまってました。現状、あとで変更はできなさそうなので作り直しました。

![Screenshot at Nov 29 16-58-24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/87adb37a-2289-a3ce-aff5-edcfea23ce2d.png)

ちなみに、両者の違いは以下をご覧ください。
https://cloud.google.com/armor/docs/security-policy-overview#policy-types

# うまくいかないとき

## ログがシンクされているかを確認

まずは、ログがシンクされているかをメトリクスで確認しましょう。

![Screenshot at Nov 29 16-51-28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/80c81ca0-13f1-e729-d5fa-527dfc4c2eb9.png)

バケットのUsageの増加でも確認できますが、ある程度ログ量がたまらないと0KiBのままです。
ちなみに、コンソールで確認する場合は、ログ用のバケットはGCSではなく、LoggingのLog Storageからになります。

![Screenshot at Nov 29 17-21-17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/7bb17b59-e91a-cff8-0099-1f68da31b03a.png)


## サービスアカウントのアクセスを確認

正常にWafCharmの設定が完了すると、サービスアカウントを使ったアクセスが発生します。
言い換えれば、このアクセスがなければ、WafCharmからのアクセスが発生していない　＝　いつまで待ってもルールは流れてきません。
今回、僕はポリシーTypeを間違えるというしくじりをしてしまったため、WafCharm側で初回でNG認識となりアクセスが来なくなりました。そのため、修正後もルールが反映されませんでした。p.m. 1:20あたりのアクセスからp.m. 3:20くらいの空白がそれです。
今回はサポートにケース起票することで、WafCharm側で再実行の対応をいただきました。
サービスアカウントのアクセスがなければ、サービスアカウントの設定を確認の上、ケース起票またはアカウントの発行からやり直す必要があります。
一方、このアクセスが継続的に確認できれば、仮にルールが流れ込んでこなくとも、設定ミスの修正で自力復旧できる可能性があります。

![Screenshot at Nov 29 16-52-21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/9283d8ff-83a2-0196-582d-3d324c9b7d45.png)


# まとめ

いくつか注意点はあるものの、サクッとCloud Armorにルールを追加することができました。
WAFのルール運用は、非常に難しい＆継続的に対応が必要なしんどい作業なので、それをマネージドにできるWafCharmは是非おすすめしたいサービスです。

幸か不幸か、設置後の4時間で、WafCharmでブロックした攻撃はありませんでした。
ただ、アクセスログを見ると、海外からのアクセスがてんこ盛り。。。
内容を見ると、探りの段階のものだけで、実際の攻撃通信ではなかったです。多分、トップページしか返さないコンテナだったので、攻撃者も素通りしたんじゃなかろうかと。
一方、通常のサービスをWAFなしで公開することのリスクも、改めて感じることができました。

また、今回、ポリシータイプを間違ったことでWafCharmのサポート担当者さんの手間をかけてしまった罪滅ぼしに、設定ミスをチェックするスクリプトを書いておきました。
今は最小限のチェックしかしてないですが、またミスが発生したらチェック事項を加筆して行こうかと。
https://gist.github.com/pict3/c9fdbbb6b38df859079f61f51499f0c4

![Screenshot at Nov 29 19-21-44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51320/dd4d672f-d62c-5496-d107-e78e9bbfc52d.png)