VPCフローログを取得してみた

こんにちは、ディーネット山田です。
今回は、VPCフローログを取得してみたいと思います。

VPCフローログとは

VPC のネットワークインターフェイスとの間で行き来する IP トラフィックに関する情報をキャプチャできるようにする機能です。
フローログデータは Amazon CloudWatch Logs または Amazon S3 に発行できます。

以下のユーザーガイドから引用させていただきました。
Amazon VPC ユーザーガイド

簡単にまとめると、VPC内を流れるパケットの通信ログを取得するサービスになります。

一般的にどういったことに使うのか（ユースケース）について

• インスタンスに接続できないといった通信トラブルの調査
• セキュリティテスト（セキュリティグループで正しく制限されているか）
• セキュリティ監査（不正アクセスの兆候監視や分析など）

フローログを取得することのできる対象について

• VPC
• サブネット
• ネットワークインターフェイス(ENI)

インスタンスのENI単体で取得することも可能だし、VPC,サブネットで取得するとその配下で抱えているすべてのENIを対象として取得可能。

これについては、要件や用途に応じて設定する箇所をそれぞれ使い分けましょう。

ログレコード形式について

• AWS のデフォルト形式
• カスタム形式

こちらの2種類から選択することになります。

• AWS のデフォルト形式については、執筆時点では以下のフォーマットがセットされています。

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}

フィールド名	説明
${version}	VPC フローログバージョン
${account-id}	トラフィックが記録されるソースネットワークインターフェイスの所有者の AWS アカウント ID
${interface-id}	トラフィックが記録されるネットワークインターフェイスの ID
${srcaddr}	受信トラフィックの送信元アドレスか、ネットワークインターフェイスにおける送信トラフィックのネットワークインターフェイスの IPv4 または IPv6 アドレス
${dstaddr}	送信トラフィックの送信先アドレスか、ネットワークインターフェイスにおける受信トラフィックのネットワークインターフェイスの IPv4 または IPv6 アドレス
${srcport}	トラフィックの送信元ポート
${dstport}	トラフィックの送信先ポート
${protocol}	トラフィックの IANA プロトコル番号
${packets}	フロー中に転送されたパケットの数
${bytes}	フロー中に転送されたバイト数
${start}	集約間隔内にフローの最初のパケットが受信された時間 (UNIX 秒)
${end}	集約間隔内にフローの最後のパケットが受信された時間 (UNIX 秒)
${action}	トラフィックに関連付けられたアクション
${log-status}	フローログのロギングステータス

詳しくご覧になりたい方は、以下をご覧ください。
使用可能なフィールド

• カスタム形式について
  AWS のデフォルト形式だけでも十分に思えますが、先ほどの使用可能なフィールドから情報として欲しいものを追加できます。

フローログの制限事項について

• 設定すると稼働中の設定に対して変更ができない（削除して再作成という手段を取れば変更は実質的に可能）
• EC2-Classicプラットフォームではフローログを有効にできない
• すべての通信が記録されるものではない
  • Amazon DNSサーバーとの通信
  • Amazon Windows ライセンスのアクティベーション通信
  • インスタンスメタデータ用(169.254.169.254)の通信
  • Amazon Time Sync Service用(169.254.169.123)の通信
  • DHCP通信
  • VPCルーターの予約済みIPアドレスとの通信

フローログの料金について

フローログは、CloudWatch LogsまたはAmazon S3に発行することができます。
どちらに発行するかで料金が異なりますが、以下のような計算式になります。

{取り込まれたデータ} + {保存されたデータ}

詳しくは、CloudWatchの料金ページにあるVended Logsの料金表をご覧ください。

では、実際にフローログを有効にしてどのようなトラフィックが記録されるのか見てみましょう

今回は、EC2のENIにてフローログを有効にして、CloudWatch Logsに発行してみました。

CloudWatch Logsへのフローログ発行するためのIAMロールを作成

IAMポリシーを作成

IAMポリシー作成画面で、"CloudWatch-Logs-VPC-Flowlog-Put-Policy"というポリシーを作成します。
※ポリシー名は、運用しやすい名前で登録をお願いします。

ポリシー内容

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

上記のポリシー内容をコピペします

ポリシー名を任意で決めます

ポリシーが作成されました

IAMロールの作成

ユースケース選択画面では、信頼されたエンティティにvpc-flow-logsを選択することができないので、公式ユーザーガイドで紹介されている方法を踏襲しEC2を選択して作成します。

ユースケースには、"EC2"を選択して作成します

IAMポリシーを選択します

• 先ほど作成した"CloudWatch-Logs-VPC-Flowlog-Put-Policy"というポリシーを選択します

IAMロール名を任意で決めます

IAMロールが作成できたので、信頼関係を変更するために選択します

信頼関係を変更します

• 信頼関係タブをクリック
• 信頼関係の編集をクリック

信頼関係の編集でServiceを変更します

• Serviceの内容を"ec2.amazonaws.com"から"vpc-flow-logs.amazonaws.com"に変更します

信頼関係の内容

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "vpc-flow-logs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

信頼されたエンティティがec2からvpc-flow-logsに変更されたことを確認します

CloudWatch Logsのロググループを作成します

ロググループ作成画面で、"/aws/vpc/yamada-vpc-flowlog-blog-test"というロググループを作成します。
保持期間は、"180日"で設定します。
※ロググループ名は、運用しやすい名前で、保持期間は要件や用途に応じて設定をお願いします。

ロググループを作成します

ロググループ名や保持期間を設定します

ロググループが作成できました

ENIにフローログの発行設定を行います

フローログを有効にしたいENIを選択します

フローログを作成します

• アクションからフローログの作成をクリック
  

フローログ設定を一通り行います

• Nameは、任意のものを設定
• フィルターは、ACCEPT（承認）、REJECT（拒否）、すべて（ACCEPT（承認）+REJECT（拒否））で要件にあったものを設定
• 最大集計期間は、要件にあったものを設定
• 送信先は、要件にあったものを設定（今回のケースであれば、CloudWatch ログに出力しました）
• 送信先ロググループは、先ほど作成したグループ名を設定
• IAMロールは、先ほど作成したIAMロールを設定
• ログレコードの形式は、要件にあったものを設定

出力されたフローログを確認する

先ほど作成したロググループ内にあるログストリームをクリックします

ACCEPT（承認）されたログ

REJECT（拒否）されたログ

まとめ

• 通信ログを取得することができるので、SSH接続できないなどと言った通信トラブルが発生した際の切り分け材料として使えますね。
• 常時取得でもよいですが、設定自体比較的容易に行えると思いますので、切り分けを実施したい時だけ短期間利用というものありだと思います。
• ログの内容を見て思った感想としては、ネットワーク系に詳しくない方は読み解くのが難しいかもしれません。