技術4課の前田です。今回はNetwork Firewallに関するお話をさせていただきたいと思います。
本記事を書いた経緯
Network Firewall（以降NFW）は通信制御に使用できるサービスですが通信のログを記録/監査したい場合にも有効です。
私の中ではVPC上にリソースを置く場合、真っ先に思い浮かぶログとしてはVPCフローログがあります。NFWログとの差異が気になり検証したため記事を書くに至りました。
結論
下記表のようにVPCフローログとNFWフローログの内容にそこまで差異はありませんでしたが、NFWアラートログでは宛先ホスト（www.serverworks.co.jp）などの通信詳細やNFWルールのアクション内容を確認することが出来ました。
| ログ種類 | 送信元IP | 送信元ポート | 送信先IP | 送信先ポート | パケット数 | バイト数 | TCPフラグ | AWS関連情報(VPC ID、サブネットID、リージョン等) | 通信詳細（HTTPS通信の場合は宛先ホストなど） | NFWルールのアクション内容 |
|---|---|---|---|---|---|---|---|---|---|---|
| VPCフローログ | 〇(※1) | 〇 | 〇(※1) | 〇 | 〇 | 〇 | 〇 | 〇 | × | × |
| NFWフローログ | 〇 | 〇 | 〇 | 〇 | 〇 | 〇 | 〇 | × | × | × |
| NFWアラートログ | 〇 | 〇 | 〇 | 〇 | × | × | × | × | 〇 | 〇 |
※1… 送信元IP/送信先IPのフィールド「${srcaddr}」/「${dstaddr}」は条件によっては中間リソースのIPに上書きされることがあるため「${pkt-srcaddr}」/「${pkt-dstaddr}」も必要になることがあります。詳細は下記リンクをご覧ください。
- ネットワークインターフェイスに複数の IPv4 アドレスがある場合、トラフィックがセカンダリプライベート IPv4 アドレスに送信されても、フローログの dstaddr フィールドにはプライマリプライベート IPv4 アドレスが表示されます。元の送信先 IP アドレスをキャプチャするには、pkt-dstaddr フィールドを含むフローログを作成します。
各ログについての説明
VPCフローログ
VPCの機能の一つで、VPC内の通信をキャプチャし、S3やCloudWatchへ記録できます。ユースケースとしてはログ監査や通信経路のトラブルシューティングに使用されます。
NFWフローログ
AWSが推奨する通りにNFWを設定すると、NFWを通過するすべての通信が記録されます。含みのある言い方をしていますが、下記記事に詳細が記載されているのでご覧ください。
フローログには、ステートレスエンジンからステートフルエンジンに転送されるトラフィックのログが記録されます。 ここで注意が必要になる点としては、Network Firewall では、ステートレスのルールにマッチするトラフィックについてはログに記録されません。
ログ記録以外の観点でも、ステートフルのルールを使用することによって、戻りトラフィックを自動的に許可したり、パケットの内容を詳細に検査することが可能となるため、ステートレスエンジンのデフォルトアクションでは「ステートフルルールグループに転送」を設定し、基本的にはすべてのトラフィックをステートフルエンジンで処理することが推奨されています。
NFWアラートログ
NFWを通過する通信の中でドロップ、アラート、拒否のアクションが設定されたルールに合致する通信詳細が記録されます。ユースケースとしては「ルールに抵触した通信があったので、その通信の詳細を確認したい」という時に役立ちます。NFWフローログとの棲み分けとしては
NFWフローログ = 通信の概要
NFWアラートログ = NFWフローログでは表示しきれない1パケットごとの通信
のようなイメージで捉えると分かりやすいかもしれません。
検証内容
検証環境について
下図のように検証用EC2から弊社WebサイトにHTTPSリクエストを送り、各ログに記録された内容を見ていきます。
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}
NFWフローログ/アラートログ設定について
今回はアラートログにも記録したいので、TCPプロトコルで行われる全ての通信をアラート扱いにしています。
その上で、フローログとアラートログをCloudWatch Logsへ転送するように設定しています。
検索対象のログ
実際に検証環境から弊社WebサイトへHTTPSリクエストを送った時の画像がこちらです。名前解決の結果、210.152.14.43へアクセスしているので左記IPをキーワードに該当ログを検索していきます。
検証結果
VPCフローログの中身
■行きの通信
検証用EC2 （192.0.2.36。srcaddr及びpkt-srcaddrに表示）から弊社Webサイト（210.152.14.43。dstaddr及びpkt-dstaddrに表示）へ通信が行われています。パケット数やサイズやTCPフラグも記載されています。
（ただの感想ですが、フィールドがなかったり時刻がUNIX形式だったりと直感的に分かりにくいです…💦）
<AWSアカウントID> ACCEPT apne1-az4 1447 210.152.14.43 443 1708942746 egress i-01c683547ceb54ac3 eni-08199fb21c10879b0 OK 16 - 210.152.14.43 - 192.0.2.36 6 ap-northeast-1 192.0.2.36 51452 1708942695 - - subnet-0438afc62f49327a5 7 1 IPv4 5 vpc-0fc0a4339dbbcc8e9
| 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 | 1447 | 210.152.14.43 | 443 | 1708942746 | egress | i-01c683547ceb54ac3 | eni-08199fb21c10879b0 | OK | 16 | - | 210.152.14.43 | - | 192.0.2.36 | 6 | ap-northeast-1 | 192.0.2.36 | 51452 | 1708942695 | - | - | subnet-0438afc62f49327a5 | 7 | 1 | IPv4 | 5 | vpc-0fc0a4339dbbcc8e9 |
■戻りの通信
弊社Webサイト（210.152.14.43。srcaddr及びpkt-srcaddrに表示）から検証用EC2 （192.0.2.36。dstaddr及びpkt-dstaddrに表示）へ通信が行われています。
<AWSアカウントID> ACCEPT apne1-az4 60806 192.0.2.36 51452 1708942746 ingress i-01c683547ceb54ac3 eni-08199fb21c10879b0 OK 48 - 192.0.2.36 - 210.152.14.43 6 ap-northeast-1 210.152.14.43 443 1708942695 - - subnet-0438afc62f49327a5 19 - IPv4 5 vpc-0fc0a4339dbbcc8e9
| 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 | 60806 | 192.0.2.36 | 51452 | 1708942746 | ingress | i-01c683547ceb54ac3 | eni-08199fb21c10879b0 | OK | 48 | - | 192.0.2.36 | - | 210.152.14.43 | 6 | ap-northeast-1 | 210.152.14.43 | 443 | 1708942695 | - | - | subnet-0438afc62f49327a5 | 19 | - | IPv4 | 5 | vpc-0fc0a4339dbbcc8e9 |
NFWフローログの中身
■行きの通信
検証用EC2 （192.0.2.36）から弊社Webサイト（210.152.14.43）への通信が行われています。
VPCフローログと同じくパケット数やサイズやTCPフラグが記載されています。一方でAWSリソース関連の情報は記載されていません。
{ "firewall_name": "nfw-blog11", "availability_zone": "ap-northeast-1a", "event_timestamp": "1708942967", "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": 51452, "netflow": { "pkts": 16, "bytes": 1447, "start": "2024-02-26T10:18:11.718646+0000", "end": "2024-02-26T10:18:11.857888+0000", "age": 0, "min_ttl": 254, "max_ttl": 254 }, "event_type": "netflow", "flow_id": 449330442139446, "dest_ip": "210.152.14.43", "proto": "TCP", "dest_port": 443, "timestamp": "2024-02-26T10:22:47.245000+0000" } }
■戻りの通信
{ "firewall_name": "nfw-blog11", "availability_zone": "ap-northeast-1a", "event_timestamp": "1708942967", "event": { "tcp": { "tcp_flags": "1b", "syn": true, "fin": true, "psh": true, "ack": true }, "app_proto": "tls", "src_ip": "210.152.14.43", "src_port": 443, "netflow": { "pkts": 48, "bytes": 60806, "start": "2024-02-26T10:18:11.718646+0000", "end": "2024-02-26T10:18:11.857888+0000", "age": 0, "min_ttl": 48, "max_ttl": 48 }, "event_type": "netflow", "flow_id": 449330442139446, "dest_ip": "192.0.2.36", "proto": "TCP", "dest_port": 51452, "timestamp": "2024-02-26T10:22:47.245039+0000" } }
NFWアラートログの中身
■行きの通信
行きのNFWフローログで「"pkts": 16」、つまり行きの通信にはパケット数が16個あると書かれていましたが、そのうちの1つを下記に記載しています。
注目する箇所は2つあると考えております。
1点目は「event.alert」セクションにてNFWルールがどのようなルールなのか、どのような対応をしたか記載されている点です。
2点目は「event.tls.sni」セクションにて宛先ホストが分かることです。今回で言えば弊社Webサイトのホスト名「www.serverworks.co.jp」が記載されています。
ドメインリストのルールグループを使用している場合などで、どのホストにアクセスしたか記録されていることはログ監査を行う上で役立つように思えます。
{ "firewall_name": "nfw-blog11", "availability_zone": "ap-northeast-1a", "event_timestamp": "1708942691", "event": { "app_proto": "tls", "src_ip": "192.0.2.36", "src_port": 51452, "event_type": "alert", "alert": { "severity": 3, "signature_id": 2, "rev": 0, "signature": "aws:alert_strict action", "action": "allowed", "category": "" }, "flow_id": 449330442139446, "dest_ip": "210.152.14.43", "proto": "TCP", "tls": { "subject": "CN=*.serverworks.co.jp", "issuerdn": "C=BE, O=GlobalSign nv-sa, CN=GlobalSign GCC R3 DV TLS CA 2020", "serial": "0D:5E:48:58:FD:EA:96:3C:8C:7E:C7:4F", "fingerprint": "50:28:c9:bd:b6:5f:d6:6b:e1:fd:20:ab:da:69:ae:48:4f:fb:b6:a1", "sni": "www.serverworks.co.jp", "version": "TLS 1.2", "notbefore": "2023-12-01T04:06:42", "notafter": "2025-01-01T04:06:41", "ja3": {}, "ja3s": {} }, "dest_port": 443, "timestamp": "2024-02-26T10:18:11.857446+0000" } }
■戻りの通信
戻りのNFWフローログで「"pkts": 48」、つまり戻りの通信にはパケット数が48個あると書かれていましたが、そのうちの1つを下記に記載しています。
{ "firewall_name": "nfw-blog11", "availability_zone": "ap-northeast-1a", "event_timestamp": "1708942691", "event": { "app_proto": "tls", "src_ip": "210.152.14.43", "src_port": 443, "event_type": "alert", "alert": { "severity": 3, "signature_id": 2, "rev": 0, "signature": "aws:alert_strict action", "action": "allowed", "category": "" }, "flow_id": 449330442139446, "dest_ip": "192.0.2.36", "proto": "TCP", "tls": { "subject": "CN=*.serverworks.co.jp", "issuerdn": "C=BE, O=GlobalSign nv-sa, CN=GlobalSign GCC R3 DV TLS CA 2020", "serial": "0D:5E:48:58:FD:EA:96:3C:8C:7E:C7:4F", "fingerprint": "50:28:c9:bd:b6:5f:d6:6b:e1:fd:20:ab:da:69:ae:48:4f:fb:b6:a1", "sni": "www.serverworks.co.jp", "version": "TLS 1.2", "notbefore": "2023-12-01T04:06:42", "notafter": "2025-01-01T04:06:41", "ja3": {}, "ja3s": {} }, "dest_port": 51452, "timestamp": "2024-02-26T10:18:11.857574+0000" } }
結論（再掲）&考察
上記の検証内容から、下記表のような比較になりました。
| ログ種類 | 送信元IP | 送信元ポート | 送信先IP | 送信先ポート | パケット数 | バイト数 | TCPフラグ | AWS関連情報(VPC ID、サブネットID、リージョン等) | 通信詳細（HTTPS通信の場合は宛先ホストなど） | NFWルールのアクション内容 |
|---|---|---|---|---|---|---|---|---|---|---|
| VPCフローログ | 〇(※1) | 〇 | 〇(※1) | 〇 | 〇 | 〇 | 〇 | 〇 | × | × |
| NFWフローログ | 〇 | 〇 | 〇 | 〇 | 〇 | 〇 | 〇 | × | × | × |
| NFWアラートログ | 〇 | 〇 | 〇 | 〇 | × | × | × | × | 〇 | 〇 |
VPCフローログとNFWフローログではほとんど差異がないため、NFWで効果的なログ監査を行いたければアラートログを設定する必要があると感じました。
しかし、全ての通信をアラートログに転送すると、今回の構成であればCloudWatch Logsのログ取り込み・保存料金が跳ね上がってしまうため転送対象の通信を絞ったりS3へ転送したりと工夫が必要になることが予想されます。
感想
フローログの「flow」とは「流れ」という意味なので、「流れが分かるログ」 = 「概要レベルのログ」という意味だったのかな…とブログを書き終わってから思い当たりました。普段何気なく使っている言葉の意味を考えていくと新たな発見があるかもしれません。
今回書いた記事の内容は地味ですが、結構気になる人は多いのではないかと考えております。どなたかの一助となれば幸いです。
