Flow Logsの活用 (2021/07/01)

https://blogs.oracle.com/cloud-infrastructure/post/working-with-flow-logs

投稿者：Ajay Chhabria

ほとんどの企業では、ネットワークトラフィックフローのログを収集、保存、分析しています。これらの情報は、接続性やセキュリティに関する問題のトラブルシューティングや、ネットワーク・アクセス・ルールが期待通りに機能しているかどうかを確認するために使用されます。オラクルは先日、Flow Logsの一般提供を発表しました。以前、Oracle Cloud Infrastructure（OCI）コンソールでFlow Logsをセットアップする方法を紹介したブログを掲載しました。様々なシナリオのサンプルログと、Flow Logsにカスタムクエリを実行して、探しているレコードだけをフィルタリングする方法を紹介しています。Flow Logsを有効にしたときに、失敗や成功のシナリオでどのようなログが見られるかを分析するのに役立ちます。

Flow Logsを扱う際には、セッションとフローの違いを理解することが重要です。フローとは、2つのホスト間でデータを運ぶ一連のパケットのことで、パケットは5つのタプルを共有しています。フローとは、2つのホスト間でデータを伝送する一連のパケットのことで、パケットは次の5つのタプルを共有しています。同じ5つのタプルを持つフローのログは、サービスによって1分ごとのバッチに集約されます。

フローはセッションと同一ではありません。フローは、セッションの一部のみを含み、一方向に移動するパケットを含みます。通常、フローは1つのセッションのデータで構成されますが、複数のセッションであっても同じ値を持つことがあります。一方、セッションは、両方向に移動するパケットを含みます。

Flow logs

ペット用品を扱う架空のEコマースサイトであるMuShopは、最近、自社のサービスをOracle Cloudに移行しました。現在MuShop社が利用しているOCIネットワークは、次の図に示すように、専門的な機能階層からなる分散型エコシステムとなっています。VCNは、インターネットゲートウェイにIPv4とIPv6の両方のルートが設定された4つのサブネットで構成されています。4つのサブネットのうち1つはIPv6が有効になっています。ネットワーク部分をシンプルに保つよう努力していますが、さまざまな技術を使用するという本質的な性質上、少し複雑になることがあります。デプロイメントとポストプロダクションの問題を避けるために、MuShopは使用するすべてのサブネットとサービスに対してフローログを有効にすることを決定しました。以下の例は、特定のトラフィックフローについて取得したFlow Logs記録のシナリオを示しています。

受け入れられたトラフィックと拒否されたトラフィック

MuShopのOCIへの移行後、アプリケーションをホスティングしているすべてのComputeインスタンスにSSHでアクセスできるようになりました。セキュリティ上の理由から、同社の管理者は、そのうちの1つのインスタンス（192.168.1.80）を注意深く監視し、送信元アドレス、送信先アドレス、送信先ポートなどの詳細を追跡したいと考えました。管理者は、Flow Logsを使用してSSHトラフィックを監視することにしました。

数分後、送信元アドレス160.34.125.175から送信先アドレス192.168.1.80、送信先ポート22へのトラフィックについて、アクション「ACCEPT」のFlow Logsレコードが確認されます。

また、同じ送信元アドレス、送信先アドレス、送信先ポートからのトラフィックを監視したいので、Flow Logsのカスタムフィルタオプションを使用することにしました。カスタムフィルターを作成するには、このComputeインスタンスを含むサブネットに作成されたサービスログで、［ログ検索で探索］をクリックします。

カスタム検索フィルターを入力するフォーマットは、「property」.「item」=「value」です。たとえば、表示されているACCEPT JSONのサンプルからいくつかの値を差し込むと、受け入れられたすべてのトラフィックを表示するカスタム検索フィルターは、data.action = 'ACCEPT'となります。 プロパティは'data'、アイテムは'action'、値は'ACCEPT'です。1つのクエリに複数のカスタム検索フィルターを追加して、きめ細かい結果を得ることができます。

このカスタム検索は、受け入れられたすべてのトラフィックをフィルタリングしますが、関連性のない余分なACCEPTフローレコードも提供します。管理者は、別のフィルターdata.sourceAddress = 160.34.125.175、data.destinationAddress = 192.168.1.80、data.destinationPort = 22を追加します。

また、同じリクエストにさらにフィルターを追加して、以下の例のように、コンパートメント、サブネット、特定のOCIDに基づいてさらに詳細な情報を得ることができます。

•     vnicsubnetcoid: Flow Logsを有効にしたサブネット内のすべてのトラフィックをフィルタリング
•     vniccompartmentocid: Flow Logsが有効なサブネットのみのコンパートメント内のすべてのトラフィックをフィルタリング
•     vnicocid 特定のVNICに対するトラフィックをフィルター

数日後、管理者は同じComputeインスタンス(192.168.1.80)にSSH接続できず、同じ宛先のREJECTトラフィックに気づきます。

この例では、192.168.1.80へのSSHトラフィック（宛先ポート22、TCPプロトコル）が拒否されています。SSH トラフィックの拒否に気づいたら、次の手順を実行します。

1.     セキュリティリストに、プロトコルにTCP、宛先ポートに22を指定したingress stateルールが設定されていることを確認します。このセキュリティリストを、コンピュートインスタンスのVNICが存在するサブネットに関連付けます。
2.     セキュリティリストが正しく設定され、トラフィックが拒否されていない場合、適切なルーティングテーブルのルールが設定されているかどうかを確認します。

この例では、すべての拒否されたトラフィックを表示するカスタムフィルターを data.action = 'REJECT.' としました。

IPV4またはIPv6トラフィック

MuShopのあるソフトウェア開発者は、複数のセカンダリIPアドレスが設定された複数のセカンダリVNICをComputeインスタンスに接続する必要があるアプリケーションを構築しています。同じ設定の別のComputeインスタンスにトラフィックを送信する際に、カスタムフィルターとしてVNIC OCIDだけに頼るのは面倒です。ここで、data.destinationAddress、data.sourceAddress、およびdata.protocolNameが登場します。これらのプロパティをカスタムフィルターとして使用すると、プライマリIPアドレスとセカンダリIPアドレスに基づいてFlow Logsを選択的にフィルタリングすることができます。この例では、IPv6アドレス2603:c020:4000:8600:d51:51b0:e082:cc16からネットワークインターフェース2603:c020:4000:8600:7571:36bd:e7a6:768cへのIPv6-ICMPトラフィックが許可されています。これらのカスタムフィルターは、ソフトウェア開発者が探している特定のデータを簡単に自動化して識別するのに役立ちます。例として、以下のようなカスタムフィルターがあります。

•     data.destinationAddress = ‘2603:c020:4000:8600:7571:36bd:e7a6:768c’

•     data.sourceAddress = ‘2603:c020:4000:8600:d51:51b0:e082:cc16’

また、data.protocolName = 'IPv6-ICMP'を使って、送信元IPアドレスから送信先アドレスまでのICMPパケットのみをフィルタリングする検索も可能です。また、data.sourcePort または data.destinationPort フィールドでフィルタリングすることもできます。IPv4ログのフィルタリングにも同じクエリが適用されます。

データがない、レコードがスキップされる

MuShopの成長に伴い、管理者はアプリケーションの仮想マシン上での1秒あたりの接続数が増えていることに気づきます。Flow Logsは、そのリソースで行われた1秒あたりの「n」個の接続すべてのレコードを記録していない可能性があります。確認のため、管理者はその仮想マシンの集計間隔の間にスキップデータのFlow Logsレコードに気づきます。このスキップは、リソースやサービスの容量制限や内部エラーが原因で発生します。このような場合、データフィールドのendTime、startTime、status、およびversionのみが設定され、残りのデータフィールドにはnullが設定されます。フローログの容量はインスタンスのサイズに比例するため、定期的にスキップデータを受信しているお客様は、インスタンスのサイズを大きくすることを検討されてはいかがでしょうか。

次の図は、カスタムフィルタータイプ「com.oraclecloud.vcn.flowlogs.QualityEvent.SkipData.」を使用しています。

MuShopの開発者は、OCI上で何十万ものバッチコンピューティングジョブを実行することにしました。彼らは、これらのジョブが1時間後に繰り返し失敗していることに気づきました。Flow Logsでも、同じ時間帯にNODATAログが記録されています。NODATAの記録は、集計間隔の間にネットワークトラフィックがネットワークインターフェースを行き来していない場合に見られます。このNODATAログを見ることで、開発者は自分のジョブ実行環境に何か問題があることをすぐに確認することができます。また、これらのジョブを実行しているComputeインスタンスのVNICでパケットが受信されていないことも確認できます。次の例では、カスタムフィルタータイプ「com.oraclecloud.vcn.flowlogs.QualityEvent.NoData.」を使用しています。

リアルタイムの診断と洞察

Flow Logsはリアルタイムに取得されますが、OCIコンソールに表示されるまでに数分かかる場合があります。パケットをリアルタイムで分析するには、tcpdumpのようなパケットキャプチャツールを実行し、wire-sharkでパケットを表示することで、これらのログを補強することができます。OCI Logging Analyticsサービスを利用すると、アプリケーションやシステムインフラからのすべてのログデータをインデックス化、エンリッチ化、集約、探索、検索、分析、相関、可視化、監視することができます。もし、処理の追加やコンプライアンス上必要なストレージのために、ログをロギングからオブジェクト・ストレージ、ストリーミング、モニタリングなどのサービスに移動させたい場合は、サービス・コネクタを作成することができます。

まとめ

Oracle Cloud Infrastructure環境で、意図したトラフィックのみを許可し、可能な限り安全で管理しやすい環境を実現することは難しいことです。このブログでは、フローとセッションの違いを説明し、MuShopの管理者と開発者がOracleのFlow Logsを設定して使用し、サブネット・トラフィックの分析、異常の検出、トラブルシューティング、接続問題の診断を簡単に行うことができることを紹介しました。Flow Logsの詳細については、ドキュメントをご覧ください。