トップ > VPC Flow Logs > VPCフローログとNetwork Firewallの各ログの内容を比べてみる

VPCフローログとNetwork Firewallの各ログの内容を比べてみる

VPC Flow Logs AWS Network Firewall
記事タイトルとURLをコピーする

CR課の前田です。今回はNetwork Firewallに関するお話をさせていただきたいと思います。

（2024/8/6追記） NFWアラートログの箇所について記載が不十分だったため大部分を書き直しました。

本記事を書いた経緯

Network Firewall（以降NFW）は通信制御に使用できるサービスですが通信のログを記録/監査したい場合にも有効です。
私の中ではVPC上にリソースを置く場合、真っ先に思い浮かぶログとしてはVPCフローログがあります。NFWログとの差異が気になり検証したため記事を書くに至りました。

前提

結論

  • VPCフローログとNFWフローログの内容にそこまで差異はない。
  • NFWアラートログではどのルールのどのアクションで評価されたのかを確認することが出来た。
  • ステートフルデフォルトアクションによって出力されるNFWアラートログでは宛先ホスト（例：www.serverworks.co.jp）なども確認することが出来た。
ログ種類 送信元IP 送信元ポート 送信先IP 送信先ポート パケット数 バイト数 TCPフラグ AWS関連情報(VPC ID、サブネットID、リージョン等) 通信詳細（宛先ホストなど） NFWルールのアクション内容
VPCフローログ 〇(※1) 〇 〇(※1) 〇 〇 〇 〇 〇 × ×
NFWフローログ 〇 〇 〇 〇 〇 〇 〇 × × ×
NFWアラートログ
（ステートフルルールグループによって出力）		 〇 〇 〇 〇 × × × × × 〇
NFWアラートログ
（ステートフルデフォルトアクションによって出力）		 〇 〇 〇 〇 × × × × 〇 〇

※1… 送信元IP/送信先IPのフィールド「${srcaddr}」/「${dstaddr}」は条件によっては中間リソースのIPに上書きされることがあるため「${pkt-srcaddr}」/「${pkt-dstaddr}」も必要になることがあります。詳細は下記リンクをご覧ください。

フローログの制限事項

  • ネットワークインターフェイスに複数の IPv4 アドレスがある場合、トラフィックがセカンダリプライベート IPv4 アドレスに送信されても、フローログの dstaddr フィールドにはプライマリプライベート IPv4 アドレスが表示されます。元の送信先 IP アドレスをキャプチャするには、pkt-dstaddr フィールドを含むフローログを作成します。

各ログについての説明

VPCフローログ

VPCの機能の一つで、VPC内の通信をキャプチャし、S3やCloudWatchへ記録できます。ユースケースとしてはログ監査や通信経路のトラブルシューティングに使用されます。

docs.aws.amazon.com


NFWフローログ

AWSが推奨する通りにNFWを設定すると、NFWを通過するすべての通信が記録されます。含みのある言い方をしていますが、下記記事に詳細が記載されているのでご覧ください。 また、後述する検査フロー図をご覧いただくと分かりやすいかと思います。

aws.amazon.com

フローログには、ステートレスエンジンからステートフルエンジンに転送されるトラフィックのログが記録されます。 ここで注意が必要になる点としては、Network Firewall では、ステートレスのルールにマッチするトラフィックについてはログに記録されません。

ログ記録以外の観点でも、ステートフルのルールを使用することによって、戻りトラフィックを自動的に許可したり、パケットの内容を詳細に検査することが可能となるため、ステートレスエンジンのデフォルトアクションでは「ステートフルルールグループに転送」を設定し、基本的にはすべてのトラフィックをステートフルエンジンで処理することが推奨されています。


NFWアラートログ

下記に該当する通信についてはパケット単位でアラートログが出力されます。ユースケースとしては「NFWを通る通信がどのルールによって評価されたかを確認したい」という時に役立ちます。

  • NFWのステートフルルールグループのアクション「アラート」「拒否」「ドロップ」の対象となる通信（※1）
  • NFWのステートフルルールデフォルトアクション「すべてアラート」「確立された接続をアラート」の対象となる通信

前述の結果に記載しましたが、上記で出力されるアラートログそれぞれでは内容が異なります。


※1…今回はアクション「アラート」を設定して検証します。


検証内容

ネットワーク構成について

下図のように検証用EC2から弊社WebサイトにHTTPSリクエストを送り、各ログに記録された内容を見ていきます。
アラートログの内容には微妙に違いがあるため、検証用EC2は2台用意し、下記のように使い分けます。

  • 1号機（192.0.2.36）…弊社Webサイトへの通信をNFWによって許可。ステートフルルールグループによるアラートアクションによってアラートログを出力する
  • 2号機（192.0.2.37）…弊社Webサイトへの通信をNFWによってドロップ。ステートフルデフォルトアクションによってアラートログを出力する


NFW設定について

NFW設定は下記画像のように設定しています。
暗黙的に通信を拒否して1号機を送信元とする通信のみ許可し、ステートフルルールグループのアクション「アラート」によってアラートログを出力する（※1）ようにしています。
一方、2号機を送信元とする通信はステートフルデフォルトアクションの「確立された接続をアラート」によってアラートログを出力するようにしています。


検査内容をフローチャートで表すと下記のようになります。


※1… アラートルールだけでなくパスルールも設定している理由は暗黙的拒否のNetwork Firewallにおいてアラートルールのみでは拒否される。パスルールも必要！をご覧ください。


VPCフローログ設定について

デフォルト設定では下記のように限られたフィールドしか記録されません。（フィールドの意味についてはVPC フローログを使用した IP トラフィックのログ記録 - Amazon Virtual Private Cloudをご覧ください。） 

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


今回は下記のフィールドを記録するようにします。 

${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}


検証対象の通信

1号機（192.0.2.36）から弊社WebサイトへHTTPSリクエストを送り、応答が返りました。これにより下記のログが出力されます。

  • VPCフローログ

  • NFWフローログ

  • NFWアラートログ（ステートフルルールグループ「nfw-rulegroup-alert」によって出力）



2号機（192.0.2.37）から弊社WebサイトへHTTPSリクエストを送りましたが、NFWによってドロップされて応答は返りませんでした。これにより下記のログが出力されます。

  • VPCフローログ（※冗長になるため検証結果には記載しません）

  • NFWフローログ（※冗長になるため検証結果には記載しません）

  • NFWアラートログ（ステートフルデフォルトアクションによって出力）


検証結果

VPCフローログの中身

1号機 （192.0.2.36）と弊社Webサイト（210.152.14.43）の通信内容です。

■行きの通信

  • 1号機 （192.0.2.36。srcaddr及びpkt-srcaddrに表示）から弊社Webサイト（210.152.14.43。dstaddr及びpkt-dstaddrに表示）へ通信が行われていることが分かります。
  • AWSアカウントIDやVPC IDなどのAWSリソース情報も記載されています。
<AWSアカウントID> ACCEPT apne1-az4 1971 210.152.14.43 443 1722933651 egress i-02b8eba2bc8b081ae eni-01b5413b051bfc8c1 OK 31 - 210.152.14.43 - 192.0.2.36 6 ap-northeast-1 192.0.2.36 52546 1722933623 - - subnet-0e106339df57f3c4e 7 1 IPv4 7 vpc-08b8566b858cfbe92
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
<AWSアカウントID> ACCEPT apne1-az4 1971 210.152.14.43 443 1722933651 egress i-02b8eba2bc8b081ae eni-01b5413b051bfc8c1 OK 31 - 210.152.14.43 - 192.0.2.36 6 ap-northeast-1 192.0.2.36 52546 1722933623 - - subnet-0e106339df57f3c4e 7 1 IPv4 7 vpc-08b8566b858cfbe92

■戻りの通信 

<AWSアカウントID> ACCEPT apne1-az4 60419 192.0.2.36 52546 1722933651 ingress i-02b8eba2bc8b081ae eni-01b5413b051bfc8c1 OK 48 - 192.0.2.36 - 210.152.14.43 6 ap-northeast-1 210.152.14.43 443 1722933623 - - subnet-0e106339df57f3c4e 19 - IPv4 7 vpc-08b8566b858cfbe92
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
<AWSアカウントID> ACCEPT apne1-az4 60419 192.0.2.36 52546 1722933651 ingress i-02b8eba2bc8b081ae eni-01b5413b051bfc8c1 OK 48 - 192.0.2.36 - 210.152.14.43 6 ap-northeast-1 210.152.14.43 443 1722933623 - - subnet-0e106339df57f3c4e 19 - IPv4 7 vpc-08b8566b858cfbe92


NFWフローログの中身

1号機 （192.0.2.36）と弊社Webサイト（210.152.14.43）の通信内容です。

■行きの通信

  • VPCフローログと同じくパケット数やサイズやTCPフラグが記載されています。一方でAWSリソース関連の情報は記載されていません。
{
    "firewall_name": "nfw-test",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1722934086",
    "event": {
        "tcp": {
            "tcp_flags": "1f",
            "syn": true,
            "fin": true,
            "rst": true,
            "psh": true,
            "ack": true
        },
        "app_proto": "tls",
        "src_ip": "192.0.2.36",
        "src_port": 52546,
        "netflow": {
            "pkts": 31,
            "bytes": 1971,
            "start": "2024-08-06T08:40:14.022844+0000",
            "end": "2024-08-06T08:40:14.194941+0000",
            "age": 0,
            "min_ttl": 126,
            "max_ttl": 126
        },
        "event_type": "netflow",
        "flow_id": 2099306486978876,
        "dest_ip": "210.152.14.43",
        "proto": "TCP",
        "dest_port": 443,
        "timestamp": "2024-08-06T08:48:06.619773+0000"
    }
}

■戻りの通信

{
    "firewall_name": "nfw-test",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1722934086",
    "event": {
        "tcp": {
            "tcp_flags": "1f",
            "syn": true,
            "fin": true,
            "rst": true,
            "psh": true,
            "ack": true
        },
        "app_proto": "tls",
        "src_ip": "210.152.14.43",
        "src_port": 443,
        "netflow": {
            "pkts": 48,
            "bytes": 60419,
            "start": "2024-08-06T08:40:14.022844+0000",
            "end": "2024-08-06T08:40:14.194941+0000",
            "age": 0,
            "min_ttl": 44,
            "max_ttl": 44
        },
        "event_type": "netflow",
        "flow_id": 2099306486978876,
        "dest_ip": "192.0.2.36",
        "proto": "TCP",
        "dest_port": 52546,
        "timestamp": "2024-08-06T08:48:06.619896+0000"
    }
}


NFWアラートログ（ステートフルルールグループによって出力）の中身

1号機 （192.0.2.36）と弊社Webサイト（210.152.14.43）の通信内容です。

■行きの通信

  • 「signature_id": 1001」とあるので、ステートフルルールグループ「nfw-rulegroup-alert」のアラートアクションが設定されているルールで評価された結果、出力されたアラートログであることが分かります。
{
    "firewall_name": "nfw-test",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1722933614",
    "event": {
        "src_ip": "192.0.2.36",
        "src_port": 52546,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 1001,
            "rev": 0,
            "signature": "",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 2099306486978876,
        "dest_ip": "210.152.14.43",
        "proto": "TCP",
        "dest_port": 443,
        "timestamp": "2024-08-06T08:40:14.022844+0000"
    }
}

■戻りの通信

  • 「コンテキストが含まれない通信は最初の1パケット目のみが評価される」というNFWアラートログの仕様から、2パケット目以降の戻りの通信は出力されません。（今回はセッションを張らずにただHTTPSリクエストを送っただけであるため、コンテキストが含まれない通信に該当したと思われます。）

Limitations and caveats for stateful rules in AWS Network Firewall

When you use a stateful rule with a layer 3 or 4 protocol such as IP or TCP, and you don't include any flow state context, for example "flow:not_established", then Suricata treats this rule as an IP-only rule. Suricata only evaluates IP-only rules for the first packet in each direction of the flow.


NFWアラートログ（ステートフルデフォルトアクションによって出力）の中身

2号機 （192.0.2.37）が弊社Webサイト（210.152.14.43）へHTTPSリクエストを送りましたが、NFWによって暗黙的に拒否された際の通信内容です。

■行きの通信

  • 「"signature": "aws:alert_established action"」と記載されていることから、ステートフルデフォルトアクションの「確立された接続をアラート」のアクションによって出力されたアラートログであることが分かります。

  • 「"action": "blocked"」と記載されていることから、通信がブロック（＝ドロップ）されたことも分かります。

  • 「"sni": "www.serverworks.co.jp"」と記載されていることから、どのドメインにアクセスしようとしたのかが分かります。
    ※HTTPS通信自体は暗号化されているので復号化しない限り中身を見ることは出来ないのですが、SNI（Server Name Indication）というTLS・SSLハンドシェイクに含まれるドメイン名を記録しているため、アラートログにも記録されています。

{
    "firewall_name": "nfw-test",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1722933652",
    "event": {
        "app_proto": "tls",
        "src_ip": "192.0.2.37",
        "src_port": 52352,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 4,
            "rev": 0,
            "signature": "aws:alert_established action",
            "action": "blocked",
            "category": ""
        },
        "flow_id": 1204600377217303,
        "dest_ip": "210.152.14.43",
        "proto": "TCP",
        "tls": {
            "sni": "www.serverworks.co.jp",
            "version": "UNDETERMINED",
            "ja3": {},
            "ja3s": {}
        },
        "dest_port": 443,
        "timestamp": "2024-08-06T08:40:52.777153+0000"
    }
}

■戻りの通信
そもそもNFWによって行きの通信がブロックされていることや、コンテキストが含まれない通信であるため戻りの通信は出力されません。

結論（再掲）&考察

上記の検証内容から、下記表のような結果となります。

ログ種類 送信元IP 送信元ポート 送信先IP 送信先ポート パケット数 バイト数 TCPフラグ AWS関連情報(VPC ID、サブネットID、リージョン等) 通信詳細（宛先ホストなど） NFWルールのアクション内容
VPCフローログ 〇(※1) 〇 〇(※1) 〇 〇 〇 〇 〇 × ×
NFWフローログ 〇 〇 〇 〇 〇 〇 〇 × × ×
NFWアラートログ
（ステートフルルールグループによって出力）		 〇 〇 〇 〇 × × × × × 〇
NFWアラートログ
（ステートフルデフォルトアクションによって出力）		 〇 〇 〇 〇 × × × × 〇 〇

VPCフローログとNFWフローログでは内容にほとんど差異はないですが、「NFWを経由する通信のログ管理・確認をする」という観点で見るならば有効化しておいてもよいのではないかと考えます。VPCフローログでNFWを経由する通信を対象に確認しようとしても、NFWを経由しない通信が混ざっていて送信先IPアドレスなどでフィルタする手間が発生するためです。

アラートログはどのルールで評価されたかを確認するために入れておいて有効化しておくと、例えばルールの誤設定をしてしまった場合などにも原因を辿りやすくなるのではないかと思います。 しかし今回のように許可対象通信にアラートログを出す場合、パケット単位で記録されることでログ取り込み・保管料金が跳ね上がってしまう可能性があることには注意が必要です。

感想

今回書いた記事の内容は地味ですが、結構気になる人は多いのではないかと考えております。どなたかの一助となれば幸いです。

前田 青秀(執筆記事の一覧)

2023年2月入社 技術4課改めCR課

AWS資格12冠

ジムに通い始めましたが、なるべく楽してマッチョになりたい…

【お知らせ】

【AWS re:Invent 2024 をエンジニアブログで振り返ろう】

2024年12月2日 - 12月6日 | ラスベガス（米国）
世界最大の AWS カンファレンス・AWS re:Invent 2024の感動をエンジニアブログで振り返りましょう！

AWS re:Invent 2024のブログ記事を読む

前田 青秀