Cloudflare Zero TrustのFree Planでセキュアゲートウェイを試してみる

:::note info
本記事は2022年11月末の確認結果を元に記載しています。進化の早いクラウドサービスに関連する情報ですので、仕様は随時変化していく可能性がある点にご注意ください。
:::

Cloudflare Zero Trustには[Cloudflare Gateway](https://www.cloudflare.com/ja-jp/products/zero-trust/gateway/)と呼ばれるセキュアゲートウェイの機能があります。今回は、Cloudflare Zero Trustのフリー版でどの程度PCのセキュリティを強化できるか試してみました。

## Cloudflare Gatewayのセキュアゲートウェイ機能のアプローチ

### Cloudflare Gatewayの超概要
Cloudflare Gatewayを使用するには、基本形としてはPCにWARPクライアントをインストール/設定する必要があります。詳細についてはこの記事では割愛しますが、ざっくり言うと、WARPクライアントとCloudflareの間でインターネット通信用のトンネルを張っていて、トンネルの出入口で通信内容を見張っているイメージになるのかなと思います。
![cfad2022-09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2339154/1bbf365c-0a1b-7c72-9389-b0b520f80f0e.png)

Cloudflare GatewayはDNSポリシー・HTTPポリシー・Networkポリシーの3つで構成されており、ポリシーには評価順序の概念があります。ざっくり、DNS→HTTP→Networkの順で評価されます。
[Order of enforcement - Cloudflare Zero Trust docs](https://developers.cloudflare.com/cloudflare-one/policies/filtering/order-of-enforcement/)

### Cloudflare Gatewayのポリシー構成

今回は2022年11月に一時的に復活したと言われる某エモいマルウェアで検証します。検体が発生させる通信に対し、DNSでの名前解決またはHTTPリクエストを捕まえられることを期待して、簡単に以下のポリシーを構成してみました。
* DNSポリシー：セキュリティリスク ブロック
* HTTPポリシー：セキュリティリスク ブロック、TLS復号 有効、アンチウィルススキャン 有効
![cfad2022-03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2339154/c661889c-689b-6e5d-cbbc-ebc977690257.png)
![cfad2022-04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2339154/9c4b96ef-b96b-ab06-7964-03a6aab1b4c3.png)

DNSポリシーとHTTPポリシーの役割イメージは以下のとおりです。

* (a) HTTPリクエスト先をホスト名(FQDN)で指定する場合、まずはDNSでホスト名を名前解決します。リクエスト先のホストがセキュリティリスク有り(マルウェア配布/C2など)と判定された場合、名前解決をブロックする(ホスト名に対応するIPアドレスを教えない)ことで、通信をできなくさせます。
* (b) 名前解決によって通信先のIPアドレスが分かったら、指定されたURLへHTTPリクエストを行います。リクエスト先のURLがセキュリティリスク有りと判定された場合、HTTPリクエストをブロックします。
* (c) HTTPリクエストに成功すると、Webサーバからコンテンツ(ファイル)がレスポンスされます。レスポンスされたデータがアンチウィルススキャンによりマルウェア判定された場合、レスポンスの通信(ダウンロード)がブロックされます。
![cfad2022-01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2339154/8f68f9d3-39ba-9830-4d2d-eedb8d25474c.png)

## 検証開始

:::note warn
注意：十分な準備・知識が無い場合、本記事のような検証をすることはお控えください。思わぬセキュリティ被害や他者への影響が生じる可能性があります。
:::

### 手順
* Cloudflare Gatewayの効果を確認するため、検証用PCのアンチウィルス機能(Windows Defender)は無効化しておきます。
* 某エモいマルウェアがメールで着弾した前提で、検体(=パスワード付きZIPファイル)を開きます。
* ZIPファイルに含まれるExcelファイル内に記載された注意書き(※1)のとおりにファイルの保存場所を変更してから、Excelファイルを開き直します。
* Excelファイルを開くと、細工されたExcel4.0マクロが実行されマルウェア本体のダウンロードが試行されます。検証に使用した検体は、4つのURLに対してマルウェア本体のダウンロードを試行する仕掛けとなっていました。
![cfad2022-10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2339154/ac4bba4b-8778-8a20-832f-6a4f036a4d7b.png)

※1 ↓Excelファイル内に記載された注意書き。マクロを実行できるディレクトリでExcelファイルを開くように誘導している。
![cfad2022-05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2339154/344bd61c-0084-d24d-82b0-17c4ea5e28c3.png)

### 結果

細工されたマクロによるマルウェア本体のダウンロードがブロックされ、マルウェア感染から無事に守られました。(マルウェア本体がダウンロードされた形跡無し、EmoCheck(※2)でも検知無し)
※2 https://github.com/JPCERTCC/EmoCheck

| - | DNSポリシー | HTTPポリシー | AVスキャン | メモ |
|:-:|:-:|:-:|:-:|:-:|
| サイトA | ブロック | -      | -        | ※3 |
| サイトB | 非検知   | 非検知 | -        | ※4 |
| サイトC | 非検知   | 非検知 | -        | ※4 |
| サイトD | 非検知   | 非検知 | ブロック | - |

※3 HTTPポリシーとアンチウィルスでもブロックできることを確認済み
※4 検体は2022年11月第2週頃にばらまかれたものであり、2022年11月末に行った本検証時はサイトBとサイトCからのマルウェア本体のダウンロードは不可の状態でした。

↓サイトAへの名前解決をブロック
![cfad2022-06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2339154/443ad53f-87c8-7c6c-190d-b4c10413f778.png)
↓サイトDからのファイルダウンロードをブロック
![cfad2022-07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2339154/fee2669a-92da-bb18-b42b-4b31d35936af.png)
↓URLhausでのサイトB・サイトCのステータス(検証時点)
![cfad2022-08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2339154/3458b5b6-bccf-e3c6-b780-833dd7b387de.png)

### 考察
本検証時点でオンラインなマルウェア配布点へのリクエストをフリー版でもしっかりとブロックできている点は評価できるのではないかと思います。

(理想としては、"怪しい通信がブロックされたからOK!"で済まさずに、ブロックログの存在を把握して不正な通信の発生理由をしっかりと対処(今回の場合はExcelファイルの削除)すべきですが、フリー版なのでそこまでの対応は難しそうですね笑)

某エモいマルウェアは正規サイトを改ざんするなどしてマルウェア本体の配布点とするケースが多い(※5)と言われていますので、検証時点でマルウェア配布がオフラインとなっていたサイト(※6)へのリクエストを余計にブロックしていない点もユーザビリティの観点で良いと思います。

その一方で、正規サイトでマルウェアがばら撒かれていたとすると、ばら撒き初期は通信を捕まえることが難しかったことも想定されます。そのため、脅威情報(マルウェア配布点やC2サーバとして使用されているホスト/ドメインやURLなど)がどれだけ早期にポリシー反映されていたのかがポイントになってきそうです。

※5 [【注意喚起】マルウェアEmotetが10カ月ぶりに活動再開、日本も攻撃対象に | LAC WATCH](https://www.lac.co.jp/lacwatch/alert/20211119_002801.html)
※6 サイト管理者が何らかの対処をするなどして、マルウェア本体のダウンロードができなくなっている。

## おわりに

Cloudflareは様々なAPIが提供されているので、スクリプトなどで[abuse.ch](https://abuse.ch/)などのコミュニティ情報をDNS/HTTPポリシーへ適用したり、NetworkポリシーでIPブロックリストを構成するような工夫をすることでGatewayを更に補強できるかと思います。

(Networkポリシーは、本検証時点では接続先サーバのカテゴリ分類やブロックリストの提供が無いようなので、このあたりに機能向上の余地があるのかなと勝手ながら想像しています。それまではAPIなどを駆使して機能を補強しましょう！)

お手軽に導入/設定でき、GUI操作もサクサク軽快で、APIも提供されていて、フリー版で使えてしまう大変ありがたいソリューションです。今後の機能拡張にも期待です。

***
※参考
https://www.ipa.go.jp/security/announce/20191202.html#L21
https://www.trendmicro.com/ja_jp/jp-security/22/k/securitytrend-20221114-01.html

※本検証に使用した検体
マクロが仕込まれたExcelファイル：abee6b4a0b4a7a31fa399fe79cdd47865922e8e6eca366f3504812d9fe1e3be9 (SHA256)
マクロによってダウンロードされるマルウェア本体(DLLファイル)：d0302ed4bc2153207022dea5cb51e151cc147f97641ab8844aa1cf03eb5cee50 (SHA256)