Cloudflare WAF で検知したイベントのアラート通知 #cloudflare

Cloudflare の WAF が検知したセキュリティイベントのアラート通知（Notification）を試します。

試験手順

本家ガイド Cloudflare Notifications

通知宛先を設定(オプション)

通知先は Email（全プラン）, PagerDuty（Businessプラン以上）, webhooks（Professionalプラン以上）があります。
Email 以外はあらかじめ通知先を定義します。

tines へのｗebhook の設定例

2. 実際の通知を作成するため、「通知（Notification）」を追加

Cloudflare プロダクトに関する様々な定義済みのアラート通知を有効にすることができます。

3. WAF アラートの通知タイプを選択

WAF のアラート通知には 2 つのタイプがあります。

セキュリティイベントアラート（Businessプラン以上）
高度なセキュリティイベントアラート（Enterpriseプラン）

今回は検知から通知までの時間も早く、柔軟な設定が可能な高度な方で進めます。

Free プランでも API を利用すれば更に細かい条件を自作アラート通知に組み込めます（後述）

通知先は Email と 1 で作成した webhook を選択しています。

4. アラート通知対象のゾーンとサービスを選択

ゾーンの選択
サービスの選択

今回は WAF のカスタムルールが生成したイベントをソースにします。
カスタムルールは firewallCustom になります。

アラート対象のアクションを絞る場合

イベントに含まれるアクションでアラートを絞りたい場合は選択が可能です。（例えば Block のみ対象にしたい、など）
デフォルトではすべてが対象になります。

これはダッシュボードでイベントを確認する際に、アクションをキーに抽出するのと同じ感覚ですね。

これで通知の作成は終わりです。

5. メイン画面から送信テスト（オプション）

「テスト」をクリックすると擬似的なアラート通知の送信ができます。

6. WAF カスタムルールの作成

実際にアラートを発生させるため、ルールを設定します。
日本からの通信をブロックして、WAF のイベントを発生させるためのルールを作っています。

7. ルールにヒットするリクエストを送信

下記の方針でリクエストを投げました。

二つのカスタムルールを用意
ぞれぞれのルールが生成したイベントを合計し、カスタムルール全体で200を超える程度のリクエストを投げる

200を超えさせる理由は後述

8. WAF アラート通知発動

およそ5分で Email と webhook が到着しました。

アラート通知のロジック（WAF編）

本家解説によると、WAF 関連のアラート通知のロジックについては、下記の数字がポイントになります

数	単位
6	時間
5	分間のバケツ
200	セキュリティイベントの数
3.5	z-score
2	時間

これらを使ったロジックは下記のとおりです。

過去6時間のセキュリティイベント数を5分間隔でカウントし、最新の値が z-score 3.5 以上かつイベント数が 200を超えている
同じイベントはその後2時間は発動されない

セキュリティイベントのアラート通知に z-score の採用や 200 のしきい値との併用についての背景や理由については、こちらの Cloudflare ブログが詳しいです。

z-score

イベントのスパイクをシミュレーションしてみましょう。

6時間を5分間隔にすると、72の計測ポイントがあります。

Cloudflare のダッシュボードの WAF イベントでも6時間の範囲にすると、値は5分間分での表示になりますね

アラート通知をトリガーするには、数字を72個並べて、最後の 201 の z-score が 3.5 以上になればよさそうです。(オソラク）

71個の数字を1-120からランダムに並べ、最後の72個めを201にして z-score を取ってみました。
最後の値(201) は 200を超え、かつ、 z-score 3.7 となり 3.5 を超えました。
こういう具合でアラート通知が発動されるんじゃないかと思います。

Rでの計算

> scale(sample)
             [,1]
 [1,]  0.84778699
 [2,]  1.08873698
 [3,]  0.55329256
 [4,]  1.24937030
 [5,] -0.91917958
 [6,] -0.43727961
 [7,] -1.24044623
 [8,] -0.89240736
 [9,]  1.54386473
[10,]  0.33911480
[11,] -0.94595180
[12,]  1.57063695
[13,] -1.32076289
[14,] -1.18690179
[15,] -0.49082405
[16,]  0.41943146
[17,] -0.24987406
[18,] -0.78531847
[19,] -1.34753511
[20,]  0.15170925
[21,] -0.54436849
[22,] -1.02626846
[23,] -0.43727961
[24,] -0.35696294
[25,] -0.67822959
[26,]  0.76747033
[27,] -1.45462399
[28,] -1.56171288
[29,]  0.25879813
[30,]  0.41943146
[31,] -0.91917958
[32,]  1.11550920
[33,] -0.99949624
[34,]  0.58006478
[35,] -0.19632962
[36,] -1.10658512
[37,] -1.53494065
[38,]  0.87455921
[39,]  0.33911480
[40,] -0.65145737
[41,] -0.11601296
[42,]  1.24937030
[43,] -0.19632962
[44,] -0.62468515
[45,]  1.27614252
[46,]  0.28557035
[47,]  0.66038144
[48,] -0.94595180
[49,] -0.57114071
[50,]  1.57063695
[51,]  0.84778699
[52,] -1.37430733
[53,]  0.09816481
[54,] -0.91917958
[55,]  1.46354807
[56,]  0.79424255
[57,]  0.60683700
[58,] -1.45462399
[59,]  0.41943146
[60,] -1.18690179
[61,]  0.17848147
[62,] -0.54436849
[63,] -0.19632962
[64,]  0.28557035
[65,]  0.33911480
[66,]  0.41943146
[67,]  0.87455921
[68,]  0.79424255
[69,]  1.06196476
[70,]  0.60683700
[71,] -0.30341850
[72,]  3.76595905
attr(,"scaled:center")
[1] 59.33333
attr(,"scaled:scale")
[1] 37.35215
>
> plot(scale(sample),type="b")
> plot(sample,type="b")

グラフにすると、これくらいのハネ加減になりました。
横軸が6時間で、過去の5分間隔のイベント数が置かれてるイメージです。

縦軸：z-score
縦軸：実数（イベント数見立て）

なお、トリガーについては、各アラート通知でそのソースイベントの性質と通知の目的によってロジックが異なります。
あくまで上記は WAF 関連のものになります。
オリジンエラーレートの例

自前でモニターの例

Analytics API（Free プランでも使える）

Analytics API でもダッシュボードと同じ様な WAF 関連の統計情報がとれます。

色々な視点からデータを分析できますので、自身で好きなトリガーを作ることができそうです。また、こちらはプランに関係なく利用できるのが利点です。

WAF アラート通知よりも細かい条件でソースを作成することができる
（下記の例では、WAF アラートにはついてない、ホスト名での絞り込みを実施）
通知の仕組みは別途用意する必要があります

下記では、直近5分で特定ホストに対してカスタムルールでブロックまたはマネージドチャレンジしたイベントの数、を取ることができます。（macOS で実施）

macOS の date

dt2=`date -Iseconds` 
dt1=`date -Iseconds -v-5M` 
cred="<TOKEN>" 
ztag="<ZONEID>"
wafsrc="firewallCustom"
action='[\"block\",\"managed_challenge\"]'
dhost="www.example.com"

curl "https://api.cloudflare.com/client/v4/graphql" -H "Authorization: Bearer $cred" -H "Content-Type: application/json" -d '{"query":"{viewer{zones(filter:{zoneTag:\"'$ztag'\"}){firewallEventsAdaptiveByTimeGroups(filter:{source:\"'$wafsrc'\",datetime_geq:\"'$dt1'\",datetime_lt:\"'$dt2'\",clientRequestHTTPHost:\"'$dhost'\",action_in:'$action'},limit:1,orderBy:[datetimeFiveMinutes_DESC]){count,dimensions{datetimeFiveMinutes}}}}}"}'

1分の場合（Linux で実施）

ubuntu の date

dt2=`date -Iseconds`
dt1=`date -Iseconds -d '1 minutes ago'`
cred="<TOKEN>" 
ztag="<ZONEID>"
wafsrc="firewallCustom"

curl "https://api.cloudflare.com/client/v4/graphql" -H "Authorization: Bearer $cred" -H "Content-Type: application/json" -d '{"query":"{viewer{zones(filter:{zoneTag:\"'$ztag'\"}){firewallEventsAdaptiveByTimeGroups(filter:{source:\"'$wafsrc'\",datetime_geq:\"'$dt1'\",datetime_lt:\"'$dt2'\"},limit:1,orderBy:[datetimeMinute_DESC]){count,dimensions{datetimeMinute}}}}}"}'

出力例

{
  "data": {
    "viewer": {
      "zones": [
        {
          "firewallEventsAdaptiveByTimeGroups": [
            {
              "count": 98,
              "dimensions": {
                "datetimeMinute": "2023-08-26T08:32:00Z"
              }
            }
          ]
        }
      ]
    }
  },
  "errors": null
}

ログ

firewallEventsAdaptive や fiwall Event ログは Adaptive sampling を採用し、イベント数の増加に応じてサンプリングを利用します。一方、Logpush（Enterpriseプラン）では HTTP リクエストログは全リクエストをとれるので、そこからロジックを組み立てることもできそうです。

Logpush 自体は new relic、Sumo Logic、Splunk など検索すると SEIM との連携も出てきます。Bigquery での分析など他にも外部とのつなぎで独自のエコシステムが作れます。

その他リンク

Cloudflare のイロイロなプロダクトの通知にタグ付けされている Blog
Free プランでのAPI 利用例
 GraphQL データセットの一覧の取り方

執筆 BGM

夏も終わりだ。。 🍺
Maysa Leak - Dangerous Summer Night