[アップデート] AWS Network Firewall でファイアウォールモニタリングダッシュボードが利用できるようになりました

こんにちは、岩城です。

本日、AWS Network Firewall にて新しくファイアウォールモニタリングダッシュボードがリリースされたので紹介します。

ファイアウォールモニタリングダッシュボード

AWS Network Firewall launches new monitoring dashboard - AWS

このダッシュボードのメリットについて、What's New には以下のように記載されています。

機械翻訳:

新しいモニタリングダッシュボードでは、上位のトラフィックフロー、TLS Server Name Indication (SNI)、HTTP ホストヘッダーなど、トラフィックパターンに関する貴重な洞察が提供されます。この詳細レベルにより、お客様は最も重要なネットワークインタラクションを迅速に特定し、分析できます。さらに、ダッシュボードでは、長時間存続する TCP フローや TCP ハンドシェイクが失敗したトラフィックフローも可視化されるため、ネットワークの問題のトラブルシューティングや潜在的なセキュリティ上の懸念事項の特定に特に役立ちます。

それでは詳しく見ていきます。

ファイアウォールモニタリングダッシュボードの前提条件

ファイアウォールモニタリングダッシュボードはデフォルトで有効化されないので、明示的に有効化しなければなりません。

有効化するには前提条件があります。

Network Firewall では以下 3 種類のログを出力することができます。

• アラートログ
• フローログ
• TLS ログ

このうち、アラートログとフローログを出力しないと、ファイアウォールモニタリングダッシュボードを有効化することができません。

さらに出力先として、CloudWatch Logs または S3 でなければならず、Data Firehose はサポート外です。

Kinesisのなごりがまだある

加えて、出力先を S3 とする場合には、以下の前提条件もあります。

• 保存先となる S3 バケットは Network Firewall と同じリージョンでなければならない
  • ダッシュボードは、Athena でクエリした結果の値が表示されます
  • Athena はクロスリージョンでのクエリをサポートしていないため、同じリージョンである必要があります
• S3 バケットのプレフィックスを指定する際、先頭に/を指定しない
  • /で始まるプレフィックスは Athena の処理と互換性がなく、ダッシュボードが正常に機能しません
• Athena API をクエリする権限があること

Network Firewall というより、Athena 都合によるものですね。

ファイアウォールモニタリングダッシュボードの考慮事項

考慮事項は以下のとおりです。

• フローログとアラートログに設定した出力先を変更または移動すると、ダッシュボードに入力されるメトリクスが不正確になる可能性がある
• S3 を出力先とした場合
  • ログデータを処理するために、アカウントに Athena のテーブルが作成される
  • 作成されたテーブルはファイアウォールモニタリングダッシュボードにのみ使用され、Network Firewall コンソールによって管理される
  • Network Firewall は、出力先の S3 バケットに Athena メタデータファイルを作成する

ダッシュボードに表示されるメトリクス

ダッシュボードに表示されるメトリクスは全部で 13 個あります。

No.	ログタイプ	メトリクス名	概要
1	フローログ	ファイアウォールのトラフィック概要	観測された接続と一意の宛先の合計数
2	フローログ	上位の有効期間が長い TCP フロー	350 秒以上アクティブであった TCP 接続
3	フローログ	上位の TCP フロー (SYN-ACK なしの SYN)	潜在的な接続の問題またはスキャンアクティビティを示す TCP 接続
4	フローログ	上位のトーカー	トラフィックに観測された最もアクティブな送信元および宛先 IP アドレス、ポート、ドメイン
5	アラートログ	ファイアウォールのトラフィック概要	拒否された接続とドロップされた接続の合計数
6	アラートログ	上位の拒否されたトラフィック	最も拒否されたドメイン、IP アドレス、ポート
7	アラートログ	上位のドロップされたトラフィック	最もドロップされたドメイン、IP アドレス、ポート
8	アラートログ	上位のアラートを受けた HTTP ホストヘッダー	トラフィック内で最も観測された HTTP ホストヘッダー
9	アラートログ	上位のドロップ / 拒否された HTTP ホストヘッダー	ドロップおよび拒否されたトラフィックで最も観測された HTTP ホストヘッダー
10	アラートログ	上位の HTTP URI パス	最もアクセスされる HTTP URI パス
11	アラートログ	上位の HTTP ユーザーエージェント	最も観測された HTTP ユーザーエージェント
12	アラートログ	上位のアラートを受けた TLS SNI	TLS トラフィックで最も観測された Server Name Indication 値
13	アラートログ	上位のドロップ / 拒否された TLS SNI	TLS トラフィックで最も観測されたドロップおよび拒否された Server Name Indication 値

利用料金

ファイアウォールダッシュボード自体は無料で利用できます。

ただし、ログを保存することに伴う CloudWatch Logs や S3 の利用料金、Athena のクエリ料金は発生します。

利用可能リージョン

Network Firewall がサポートされているすべてのリージョンで利用可能です。

実際に確認してみる

以下の構成の検証環境を作成し、EC2 インスタンスから Network Firewall を経由してインターネットにリクエストしてみました。

検証環境の作成方法の説明は割愛します。

ファイアウォールモニタリングダッシュボードは、後から有効化・無効化することができます。

本エントリでは、Network Firewall を作成する際に、アラートログとフローログは S3 に出力させ、ファイアウォールモニタリングダッシュボードを有効化します。

作成した Network Firewall のモニタリングとオブザーバビリティからファイアウォールモニタリングダッシュボードを確認できます。

実際に試してみて分かったのですが、ダッシュボードの値は自動で反映されません。上部のメニューから選択した範囲の値が反映されます。

私は時間経過と共に反映されると思い込み、範囲指定せずにリロードしながらしばらく待っていたので注意です。

上位 10, 50, 100 と表示期間の組み合わせで範囲指定ができます。

以下は、適当に EC2 から Network Firewall を経由してインターネットにリクエストした場合の結果です。

このダッシュボード表示のために裏で Athena がログクエリしているようですね。

なお、ダッシュボードに反映された値は長時間保持されないようで、反映された直後は保持されていましたが、数分経つとクリアされてました。

何度もダッシュボードを参照する際は要注意です。

つぎに、考慮事項にあったダッシュボードを表示するために Athena のテーブルが作成されることを確認してみました。

以下のように Athena のクエリエディタにある最近のクエリから、外部表を作成してドロップしていることを確認できました。

さいごに、後から無効化してみました。

すぐに反映されファイアウォールモニタリングダッシュボードが非表示になることを確認できました。

おわりに

Network Firewall を本番利用している場合、既にフローログやアラートログの出力を設定していると思うので、有効化して試してみてください。

出力されたログに対するクエリの結果をダッシュボードに表示するものなので、既存環境への影響は軽微だと思います。

個人の検証環境で組織利用時の状況を再現するのが難しく実際に確認できていないのですが、組織的に利用している環境ではログ量が多くなると思い、以下の点が個人的に気になっています。

• Athena のクエリ時間増加に伴いダッシュボードの表示に時間が掛からないか
• Athena の利用料金
  • Athena はスキャンしたデータ量に応じて課金される

いつか確認できる機会がありましたら、共有したいと思います。

本エントリが、どなたかのお役に立てれば幸いです。