連載

2023年3月9日

ネットワーク監視とフロー情報の基礎知識――AWS「VPCフローログ」設定の基本：AWSで学ぶクラウド時代のネットワーク基礎知識（7）

これまであまり物理的なネットワークに触れてこなかったエンジニアを対象に、AWSを用いてネットワークの基礎知識を解説する連載。今回は、ネットワーク監視とフロー情報の基礎知識について解説し、「VPCフローログ」の設定を通して、通信内容のフロー情報を収集する方法を示す。

[東竜一，ネットワンシステムズ] PC用表示関連情報

LINE

Hatena

　これまであまり物理的なネットワークに触れられてこなかったSEやサーバ管理者、情シスなどの方を対象にネットワークの基本を「Amazon Web Services」（AWS）を用いて解説する本連載「AWSで学ぶクラウド時代のネットワーク基礎知識」。

　今回は、ネットワーク監視について解説します。サーバなどの管理、監視にも利用される「Syslog」や「SNMP」（Simple Network Management Protocol）機能およびネットワークの監視に利用されるフロー情報を紹介した後に、AWSで利用できるフロー情報を利用したネットワークの監視機能について解説します。

ネットワークの監視

　ネットワーク管理に携わる皆さんは、ネットワークをどのように監視しているでしょうか。

　監視サーバやストレージなどと同様にネットワーク機器についても日々の運用や障害検知のためにSyslogを利用し、各機器で生成されるログ情報を収集していると思います。また「MIB」（Management Information Base）というデータベースに基づいて機器内のさまざまな情報を管理し、障害発生時には「Trap」という機能で通知するSNMPも利用していることでしょう。SNMPを利用すると、機器のインタフェースの通信量を定期的にポーリングして収集することで通信量を可視化することも可能です。一般的な企業で利用するネットワーク機器なら、これらの機能を標準的に利用できます。サーバなどの管理で利用している管理ツールでも管理できます。

通信情報のフロー化

　ただしSyslogやSNMPでは、通信情報までは確認できないので、ネットワークレベルの監視機能として、通信トラフィックを送信元／宛先IPアドレスやプロトコルなどの情報をキーとして異なる「フロー」に分類し、リスト形式で記録して管理する機能が存在します。各機器でフロー情報を生成し、「フローコレクタ」というサーバに送信させて収集することによって、過去から現在のフロー単位の通信量の可視化をはじめ、障害が発生していないかどうか、異常／セキュリティ的に問題のある通信が存在していないかどうかなど、対象ネットワークの通信情報を一元的に監視、管理することが可能になります。

　通信情報をフロー化し、収集する機能は、ネットワーク機器メーカーによって個々に実装されています。Cisco Systemsの「NetFlow」（RFC 3954で標準化）、Juniper Networksの「J-Flow」などです。RFC 3176、RFC 6526として標準公開されている「sFlow」「IPFIX」もあります。

フロー情報のみを収集する5つの理由

　なお、通信内容全ての記録と保管（通信パケットの全保管）が可能ならば、より詳細に情報を分析できますが、フロー情報のみを収集する理由としては次の5点が挙げられます。

通信内容を全て保管するには通信と同量のストレージが必要になる
各ネットワーク機器で転送される通信をドロップすることなく通信内容を保管するストレージに転送できる必要がある
通信内容全てを保管したとしても、その内容全てを分析するのは難しい
情報が流出した場合の影響が大きい
会社や団体のポリシーによっては通信内容の確認はポリシー違反になる可能性がある

　1については、フロー情報のみを保管する場合、詳細なユーザーデータまでは保管しないのでストレージの要求量は低くなりますが、通信内容全てとなるとその量に応じたストレージが必要となり、通信量が多い環境では現実的ではありません。

　2については、ネットワーク機器と通信内容を保管するストレージが直結されているなら、通信をストレージ宛てにコピーすればよいだけですが、離れている場合は何らかの方法で通信内容をストレージまで転送できるようにする必要があります。通常のネットワークを通す場合、ドロップされないようにネットワークに余剰の転送能力を確保しておく必要が生じます。あるいは通常のネットワークを通さないようにするために専用のネットワークが必要になるかもしれません。

　3については、通信内容全てを保管する場合、それらのデータは内容が異なっており、画一的なデータ分析は不可能です。データごとに分析の仕組みを作る必要があります。また大量のデータをリアルタイムに分析するコンピュータリソースが必要となり、現実的ではありません。

　4については、攻撃者からサイバー攻撃を受けるなどによって情報が流出した場合、通信内容が見られてしまい、非常に大きな問題になりかねません。その対策として、データ保存時に暗号化しておけば流出した際のリスクは低くなりますが、リアルタイムの暗号化処理に相応のコンピュータリソースが必要ですし、暗号鍵の管理を徹底する必要が生じます。

　5については、会社などのポリシーによっては通信情報を確認することは禁じられている可能性がありますが、フロー情報レベルであればユーザーデータまでは確認できないために許容される可能性が高くなります。

AWS環境でのネットワーク監視

　ここからはAWS環境でネットワークを監視するためにフロー情報を収集、監視する方法を紹介します。

VPCフローログとは

　AWSには「VPCフローログ」という機能があり、これを「Amazon Virtual Private Cloud」（VPC）で有効にすることで、VPC内で対象とする通信内容のフロー情報を収集できます。

　厳密にはネットワークインタフェース（Elastic Network Interface）の送受信トラフィックが対象となります。VPCやサブネットをフローログの対象として設定した場合、フローログの設定後に作成されたネットワークインタフェースも含めて、VPCやサブネットの中に存在するネットワークインタフェースが自動でフローログの対象となります。

　また、個々のネットワークインタフェースに対してフローログを設定することもできます。この仕組みから、下記のようなネットワークインタフェースを利用する機能もフローログの対象にすることができます。

AWS Elastic Load Balancing
Amazon Relational Database Service（RDS）
Amazon ElastiCache
Amazon Redshift
Amazon WorkSpaces
NATゲートウェイ
トランジットゲートウェイ

　フローログを有効にする際は、フローログ情報の保管先を下記から選択することになります。

Amazon CloudWatch Logs
Amazon S3バケット
Amazon Kinesis Firehose

　ネットワーク監視の観点では、1のCloudWatch Logsを利用すると、CloudWatchの仕組みでログの分析や監視が可能となります。

　CloudWatch Logsについて補足すると、CloudWatchはAWSリソースとAWSで実行するアプリケーションのモニタリングサービスです。その仕組みを利用すると、フロー情報を統合的に管理できます。具体的には、専用のクエリ言語によって、収集したフローログの内容を分析し、その結果をグラフで可視化したり、しきい値を設定して異常を検知させてメールなどで通知させたりすることが可能です。

　Amazon S3バケットでは、収集したフロー情報を、指定したS3バケットにテキスト形式で保管できます。これによってフロー情報をそのまま参照したり、S3上のデータをSQLで検索できる「Amazon Athena」サービスによってS3バケットの内容を検索したり、容易に外部のツールと連携させたりすることができます。

　Amazon Kinesis Firehoseは、大量のストリーミングデータをリアルタイムに処理するために利用されるサービスです。送信先として指定することで、フローログをリアルタイムに処理させることができます。

　ここからは、フローログで収集できるログ情報の例や監視の方法を紹介します。

フローログで収集できるログ情報の例

　下図はCloudWatchの「ロググループ」という項のページです。

　フローログの作成を設定したVPC配下のネットワークインタフェースのフローのログを取りためるログストリームが自動で生成されています。

　下図は、VPC内の、ある仮想マシン（IPアドレス：192.168.0.62）のネットワークインタフェースにおける、同じVPC内の別の仮想マシン（IPアドレス：192.168.0.102）にPingした際のフローログです。

　この環境ではフローログの項目として、2エントリ目のようにデフォルト*1のままにしたものと、1エントリ目のように取れる項目全て*2を取得するように設定したものの両方が保管されています。

*1デフォルトの取得項目は「${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}」です。

*2全項目取得の場合の取得項目は「${account-id} ${action} ${az-id} ${bytes} ${dstaddr} ${dstport} ${end} ${flow-direction} ${instance-id} ${interface-id} ${log-status} ${packets} ${pkt-dst-aws-service} ${pkt-dstaddr} ${pkt-src-aws-service} ${pkt-srcaddr} ${protocol} ${region} ${srcaddr} ${srcport} ${start} ${sublocation-id} ${sublocation-type} ${subnet-id} ${tcp-flags} ${traffic-path} ${type} ${version} ${vpc-id}です。

　上図の出力では内容が判別しにくいので、参考までに2、5、6エントリ目のデフォルトの内容について表形式で記載します。

　なお、記録開始／終了時間のフォーマットはUNIX時間です。また送信元／宛先ポート番号は0ですが、これはICMPプロトコルであり、Layer4の情報がないからです。

　上記のエントリ中に「アクション」という項目があり、「ACCEPT」となっていますが、これはセキュリティグループあるいはNACL（Network Access Control List）で通信が許可されたことを示しています。拒否された場合は「REJECT」となります。これによって拒否された通信の確認に利用することもできます。

CloudWatchインサイトで通信内容を分析

　「CloudWatchインサイト」という機能を使うと、クエリ言語によるクエリが可能になり、容易に通信内容を分析できます。下図では「CloudWatch-Log」というロググループに記録されているフロー情報からフィールドとして「タイムスタンプ」「メッセージ」「ログストリーム」「ログ名」を取り出し、「タイムスタンプ」の降順で並び替えさせ、表示件数を5件に絞らせています。

　その結果が画面下部の情報ですが、対象のフローのリストに加え、リストされたフローのレコード数が時系列に可視化されていることを確認できます。

アラームの生成

　異常などの自動検知を実現する方法として、指定した条件にマッチするフローを取り出し、その内容に対してアラームを生成することもできます。下図は極端な例ですが、「5分以内に1つでもACCEPTとなったフローが存在した場合にアラームを挙げる」と設定していて、常時アラームが挙がっている状態となります。

アラームをAmazon SNSでメールに通知

　アラーム機能は通知サービス「Amazon Simple Notification Service」（SNS）と連携させることができ、アラーム発生時に通知できます。例えばAmazon SNSでアラーム発生時に指定のメールアドレスに対してメールを送付するように設定すると、アラーム発生時に下図のようなメールを受信できます。これによってフロー情報からネットワークを監視できます。

まとめ

　今回はネットワーク監視で利用されるSyslogやSNMP、フロー機能の説明およびAWSのVPCフローログサービスの機能と利用方法を解説しました。

　これにて連載は終了です。本連載をご覧いただきありがとうございました。皆さまの今後の業務に役立てば幸いです。

Appendix

　ここからはVPCフローログの設定手順を紹介します。下図は、本稿のAWS環境の構成です。

　VPCフローログはVPC、サブネットあるいはネットワークインタフェースのオプションとして設定しますが、本環境ではVPCにフローログを設定します。なお、VPCおよびサブネットで指定した場合は移行で作成されるネットワークインタフェースも含め、当該VPC／サブネット内に存在するネットワークインタフェースがフローログの取得対象となります。

フローログの作成

　まず、VPCの設定ページでVPCを1つ選択すると画面下部に表示されるタブに「フローログ」という項目が表示されるので、選択します。その画面に表示される「フローログを作成」というボタンを押します。

　表示されるフローログ作成のページでフローログのパラメーターを指定後、「フローログ作成」ボタンを押します。

・フィルタ

　フローログを作成する通信として、セキュリティグループあるいはNACLで承諾（ACCEPT）あるいは却下（REJECT）されたパケット、あるいはその両方を選択します。

・最大集約間隔

　パケットのフロー情報を収集してからレコード化するまでの時間を10分間か1分間から指定します。10分間を指定した場合に対して1分間は10分で10レコード作られることになり、詳細な時間間隔でフロー情報を生成できるものの、その分フローのレコード数が増えることになります。

・送信先

　送信先をCloudWatch Logs、Amazon S3バケット、Kinesis Firehoseから選択します。それぞれの内容は本文を参照してください。ここではCloudWatch Logsを指定します。これによって、以降の2つのパラメーター（送信先ロググループとIAMロール）を指定することになります。S3バケットなら対象S3バケットのARN（Amazon Resource Names）、Kinesis FirehoseならKinesis Firehose配信ストリーム名（同じアカウントの場合）や、ARN（異なるアカウントの場合）を指定することになります。

・送信先ロググループ（CloudWatch Logs用パラメーター）

　フローログの情報を送付するロググループを指定します。複数のフローログを1つのロググループに送付させることもできます。

・IAMロール（CloudWatch Logs用パラメーター）

　CloudWatch Logsにフローログを送付するためのIAM（Identity and Access Management）ロールを指定します。適切なIAMロールがない場合は、「アクセス許可を設定」のリンクからIAMロールの作成ページに遷移して作成します。作成方法は後述しますが、権限に関する設定なので「CloudWatch Logsへのフローログの発行 - Amazon Virtual Private Cloud」の確認を推奨します。

・ログレコード形式

　通信内容のフロー化において、フローを構成するフィールドを指定します。AWSデフォルト形式と任意のフィールドを指定できるカスタム形式から選択します。

　上記操作の結果、下図のようにVPCのオプションとしてフローログを設定できたことを確認できます。

IAMロールの作成

　CloudWatch Logsの利用に必要なIAMロールを作成するには、IAMのページにある「ロール」の「ロールを作成」ボタンを押して進めます。

　次のページで、信頼されたエンティティタイプから「カスタム信頼ポリシー」を選択し、下に表示されるカスタム信頼ポリシーの「"Principal": {}, 」の{}の中に「"Service": "vpc-flow-logs.amazonaws.com"」と記入してVPCフローログを設定できるPrincipalを割り当て、右下の「次へ」ボタンを押します。

　次のページでIAMロールにひも付けるIAMポリシーを作成するために、「ポリシーを作成」ボタンを押します。

　表示されるポリシーの作成画面で「JSON」タブを押し、表示されるテキストボックスに下記の内容を設定し、「次のステップ：タグ」ボタンを押します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": "*"
    }
  ]
}

　次のタグの設定ページは必要に応じてタグを設定します。「次のステップ：確認」ボタンを押して確認画面でポリシーの名前を指定し、「ポリシーの作成」ボタンを押下します。

　ポリシー作成後、ロールの作成画面のページに戻ります。作成したIAMポリシーが一覧にない場合は右上の更新ボタンを利用できます。ポリシーのリストから作成したポリシーを選択し、「次へ」ボタンを押します。表示されるポリシーが非常に多く分かりにくいので、下図では検索欄で作成したポリシー名を指定して作成したポリシーのみを表示しています。

　次の画面でロール名を指定し、表示されている内容に問題ないことを確認したら、「ロールを作成」ボタンを押します。

　ロールページではVPCフローログで利用できるIAMロールができたことを確認できます。

　IAMロールを作成できたら、フローログ設定画面に戻ってください。

ロググループの有無を確認

　ここからは、CloudWatchの画面に移動し、作成されたフローログの内容を確認します。まずは作成したロググループが存在することを確認します。

　ロググループ名をクリックすると、ロググループの詳細ページに遷移します。その画面下部の「ログストリーム」に「ネットワークインタフェース名-all」という名前のログストリームが自動で作成されていることを確認できます。

　任意のログストリームを選択すると、ログイベントとしてフロー情報を確認できます。

　「ログのインサイト」機能で指定のロググループにクエリを実行することで柔軟に目的のフロー情報を取り出すこともできます。

アラームの設定

　まず、アラームを挙げる要因となるメトリクスを作るために、ロググループの詳細画面の下にある「メトリクスフィルター」タブで「メトリクスフィルターを作成」ボタンを押します。

　表示される画面で、フィルターパターンとして「ACCEPT」と入力します（セキュリティグループおよびNACLで通信を許可されたフローを対象とします）。

　メトリクスの内容を指定し、「Next」ボタンを押します。下図は内容の一例です。

　内容に問題がないことを確認し、「メトリクスフィルターを作成」ボタンを押します。

　次に「すべてのアラーム」に移動し、「アラームの作成」ボタンを押します。

　表示される画面でアラームの対象を選択するために「メトリクスの選択」ボタンを押します。

　下部の「参照」タブで、カスタム名前空間から「test」タイルを押し、続けて「ディメンションなしのメトリクス」タイルを押します。表示されるメトリクスから「ACCEPT」を選択し、「メトリクスの選択」ボタンを押します。

　表示されるページで指定のメトリクスにアラームを挙げる条件を指定します。以下では統計を「合計」に、ACCEPTが「次の時...」の箇所を「以上」に、「...よりも」を「1」に設定しています。設定が完了したら「次へ」ボタンを押します。

　次にアクションの設定画面に遷移します。アラーム状態トリガーは、今回の設定ではアラーム発生時に通知を発生させることを目的としており、「アラーム状態」を選択します。通知用のマネージサービスAmazon SNSを利用して通知できるようになっています。「既存のSNSトピックを選択」を指定し、通知の送信先として最初から存在する「Default_CloudWatch_Alarms_Topic」を選択します。このトピックではメールによる通知が可能になり、宛先アドレスとして自身のアドレスを指定しています。設定に問題がなければ「次へ」ボタンを押します。

　次のページでアラーム名などを設定し、「次へ」ボタンを押します。

　最後に設定の確認画面が出ますが、問題なければ「アラームの作成」ボタンでアラームを作成します。

　下図のようにアラームができていることを確認できます。また少し時間がたつと状態が「アラーム状態」となります。このタイミングでメールによってアラームが通知されます。

　上記の設定によって送付されたメールのアラーム通知は下図の通りです。

筆者紹介

東竜一

ネットワンシステムズ株式会社セールスエンジニアリング本部サービス開発運営部

大阪大学大学院情報科学研究科出身。2008年ネットワンシステムズ入社。

学生の頃からネットワークに非常に興味を持ち同社に入社。そこから10年近くCisco Systemsのルーター／スイッチ製品担当として、製品検証、案件支援、技術問い合わせ対応などを精力的に実施。その後、同社のマルチクラウド閉域接続サービス「クラウドHUB」の管理者としてチームを率いてサービス開発／運用、案件対応を実施中。

ネットワーク監視とフロー情報の基礎知識――AWS「VPCフローログ」設定の基本：AWSで学ぶクラウド時代のネットワーク基礎知識（7）