ネットワークファイアウォールのログ分析でセキュリティ向上を実現
Author : 飯島 卓也
こんにちは。Security Specialist TAM の飯島です。
この記事では、Amazon CloudWatch Logs Insights を使用して、AWS Network Firewall のログ分析を実施する方法を紹介します。
AWS Network Firewall は、セキュリティグループ や ネットワークアクセスコントロールリスト (NACL) とは異なる、きめ細かい高度なネットワークトラフィックの検査をすることができるマネージドサービスです。AWS Network Firewall を導入する際には、Amazon Virtual Private Cloud (VPC) 内に、どのような構成でファイアウォールを配置するのか、またファイアウォールのルールによって、どのようなトラフィックをフィルタリングするのか検討することになります。また、これに加えて、運用においてどのようにログを分析するのかを検討することも重要です。
ログ分析を通じて、ネットワーク内のトラフィックパターンを把握することにより、ポリシーの調整やルールの変更を行い Network Firewall の構成を最適化することができます。さらに、ネットワーク内の異常なアクティビティを可視化することによって、セキュリティを向上させることができます。
AWS Network Firewall の構成要素
AWS Network Firewall のログ記録や分析の説明をする前に、Network Firewall の構成要素 について説明します。
主な構成要素としては、ファイアウォール、ファイアウォールポリシー、ルールグループの 3 つに分類することができ、下図に示す通り、ネットワークトラフィックに対する検査と処理の方法を定義したルールグループがファイアウォールポリシーという形でまとめられ、そのファイアウォールポリシーがファイアウォールに関連付けられます。ファイアウォールに関連付けることができるファイアウォールポリシーは 1 つだけです。またルールグループには、ステートレスのルールグループとステートフルのルールグループがあり、ステートレスエンジンやステートフルエンジンのデフォルトアクションやルールグループをどのような順番で処理するのかをファイアウォールポリシーで設定します。
ファイアウォールを作成すると指定したサブネットでファイアウォールエンドポイントが利用可能になりますので、Network Firewall でトラフィックを検査するためには、VPC のルートテーブルを変更してトラフィックがファイアウォールエンドポイントに転送されるようにします。
Network Firewall のデプロイ方法の詳細については、AWS ブログ「AWS Network Firewall のデプロイモデル」を参照してください。
AWS Network Firewall のログ記録設定
AWS Network Firewall のログ記録はファイアウォール全体での設定となり、アラートログとフローログの 2 種類のログを取得することができます。
アラートログには、ステートフルルールグループでドロップ、アラート、拒否のアクションが設定されたルールにマッチするトラフィックのログが記録されます。フローログには、ステートレスエンジンからステートフルエンジンに転送されるトラフィックのログが記録されます。
ここで注意が必要になる点としては、Network Firewall では、ステートレスのルールにマッチするトラフィックについてはログに記録されません。
ログ記録以外の観点でも、ステートフルのルールを使用することによって、戻りトラフィックを自動的に許可したり、パケットの内容を詳細に検査することが可能となるため、ステートレスエンジンのデフォルトアクションでは「ステートフルルールグループに転送」を設定し、基本的にはすべてのトラフィックをステートフルエンジンで処理することが推奨されています。
また、ログの出力先としては、アラートログとフローログそれぞれ、Amazon Simple Storage Service (S3) バケット、Amazon CloudWatch ロググループ、Amazon Kinesis Data Firehose の 3 つから選択することができます。
ログ分析の観点では、Amazon Athena や SIEM on Amazon OpenSearch Service を使用する場合には S3 バケット、CloudWatch Logs Insights を使用する場合には CloudWatch ロググループ、リアルタイムにログを処理したりサードパーティの SIEM ソリューションに配信する場合は Kinesis Data Firehose など、分析ツールによって出力先を選択することができます。
それぞれの分析ツールに特徴がありますが、この記事の後半では実装や分析が比較的容易な CloudWatch Logs を使用したログ分析の例を紹介します。
クリックすると拡大します
フローログとアラートログの例
それでは、次にフローログとアラートログの記録設定をした場合にどのようなログが出力されるのか見てみましょう。
まず初めに、以下にフローログの出力例を示します。フローログでは、"event_type" が "netflow" となっており、どこから、どこ宛に、どのようなプロトコルで通信を実施したのか、そしてその通信はいつ開始されていつ終了したのか、転送されたパケット数やバイト数がどのくらいかという情報を確認することができます。また、フローログは 2 つのホスト間における単一方向の通信ログとなっているため、双方向の通信を確認する場合には、"flow_id" の値をもとにログを抽出して 2 つのホスト間の通信状況を確認します。
さらに、フローログには、ファイアウォールのルールでどのような処理が実施されたのかアクションの情報は記録されないという点にも留意が必要です。フローログによってファイアウォールのステートフルエンジンに転送されたトラフィック全体の可視化ができる一方で、ファイアウォールとしてのイベントを確認するためにはアラートログを中心に分析を実施します。
{
"firewall_name": "AnfwDemo-InspectionFirewall",
"availability_zone": "us-west-2a",
"event_timestamp": "1692338117",
"event": {
"tcp": {
"tcp_flags": "1f",
"syn": true,
"fin": true,
"rst": true,
"psh": true,
"ack": true
},
"app_proto": "tls",
"src_ip": "10.0.5.158",
"src_port": 59224,
"netflow": {
"pkts": 18,
"bytes": 3345,
"start": "2023-08-18T05:52:17.892303+0000",
"end": "2023-08-18T05:52:37.925802+0000",
"age": 20,
"min_ttl": 254,
"max_ttl": 254
},
"event_type": "netflow",
"flow_id": 585148610485647,
"dest_ip": "52.94.185.43",
"proto": "TCP",
"dest_port": 443,
"timestamp": "2023-08-18T05:55:17.294773+0000"
}
}以下に、アラートログの出力例を示します。アラートログは、"event_type" が "alert" として記録されるファイアウォールのイベントログです。アラートログから判別できる情報としては、どこからどこ宛の、どのような通信が許可されたのか、またはブロックされたのか、さらにその際にファイアウォールのどのルールにマッチしたのかを確認することができます。
以下の出力例では、送信元 IP アドレス 10.0.5.158 から宛先 IP アドレス 93.184.216.34 の 80 番ポートに対して HTTP 通信が行われており、宛先ホスト www.example.com がドメインリストの拒否リストにマッチしているため、当該通信がブロックされたことがわかります。
ドメインリストにマッチしたことは、"alert" 内の "signature" フィールドに出力されている "matching HTTP denylisted FQDNs" というメッセージから判断することができ、ブロックされたことは同様に、 "action" フィールドに出力されている "blocked" のログから判別することができます。
{
"firewall_name": "AnfwDemo-InspectionFirewall",
"availability_zone": "us-west-2a",
"event_timestamp": "1692407353",
"event": {
"tx_id": 0,
"app_proto": "http",
"src_ip": "10.0.5.158",
"src_port": 47162,
"event_type": "alert",
"alert": {
"severity": 1,
"signature_id": 2,
"rev": 1,
"signature": "matching HTTP denylisted FQDNs",
"action": "blocked",
"category": ""
},
"flow_id": 2083192655408943,
"dest_ip": "93.184.216.34",
"proto": "TCP",
"http": {
"hostname": "www.example.com",
"url": "/",
"http_user_agent": "curl/8.0.1",
"http_method": "HEAD",
"protocol": "HTTP/1.1",
"length": 0
},
"dest_port": 80,
"timestamp": "2023-08-19T01:09:13.906355+0000"
}
}Network Firewall のステートフルルールグループの処理はオープンソースの侵入防御システム (IPS) である Suricata によって制御されており、"event" 内の情報は Suricata EVE JSON フォーマット で出力されています。ログ分析の際に、具体的に着目する主要なフィールドとその説明については下表を参照してください。
| フィールド | 説明 |
| firewall_name | ログを出力したファイアウォールを示します。複数のファイアウォールを運用している場合には、このフィールドから特定のファイアウォールを識別することができます。 |
| event.event_type | ログの種別として、アラートログかフローログを識別することができます。 |
| event.alert.action | ファイアウォールのアクションとして、対象の通信を許可したのかブロックしたのかを記録します。 |
| event.alert.signature_id | マッチしたシグネチャ ID を示します。この情報をもとに、ステートフルルールグループのどのルールにマッチしたのかを特定することができます。 |
| event.alert.signature | マッチしたシグネチャの情報を示します。この情報をもとに、ドメインリストや Suricata 互換 IPS ルール、マネージドシグネチャ、それぞれどのシグネチャにマッチしたのかを識別することができます。 |
| event.alert.metadata.signature_severity.0 | シグネチャのメタデータとしてシビラティが記載されている場合に表示されます。不審なアクティビティを検知した場合に、この情報をもとに対応の優先度を判断することができます。 |
| event.app_proto | アプリケーションレイヤーのプロトコルを示します。 |
| event.src_ip | 送信元 IP アドレスを示します。 |
| event.src_port | 送信元 ポート番号を示します。 |
| event.dest_ip | 宛先 IP アドレスを示します。 |
| event.dest_port | 宛先 ポート番号を示します。 |
| event.proto | IP やトランスポートレイヤーのプロトコルを示します。 |
| event.tls.sni | TLS SNI (Server Name Indication) の情報から TLS 通信の宛先ホストを確認することができます。 |
| event.http.hostname | HTTP Host ヘッダの情報から、HTTP 通信の宛先ホストを確認することができます。 |
| event.timestamp | イベントが発生した時刻を示します。 |
ファイアウォールのアクション
アラートログから、特定の通信がファイアウォールで許可されたのか、ブロックされたのか確認することができるという説明をしましたが、許可されたことを示すログを取得するためには留意すべき点もあります。ここではファイアウォールのステートフルルールのアクション設定とログ取得の動作についてもう少し詳しく見ていきたいと思います。
注: Network Firewall では、ステートフルルールグループを評価する順序として「アクション順」に評価をする方式と優先度に基づいて順番に処理される「厳格」と呼ばれる方式の 2 つがありますが、ここでは「厳格」方式において、標準ステートフルルールや Suricata 互換 IPS ルールを設定する構成を前提としています。
「厳格」方式では、ルールの最後にデフォルトアクションとして先に定義されたルールにマッチしないすべてのパケットをドロップする設定が利用可能なため、特定の通信のみを許可してそれ以外をドロップするファイアウォールを構成する場合に適した方式です。
この記事では、Network Firewall のログ分析をテーマとしていますので、2 つの評価方式の詳細については、AWS Network Firewall 開発者ガイドの Evaluation order for stateful rule groups の箇所や AWS ブログ「AWS Network Firewall 柔軟なルールエンジンのハンズオンウォークスルー (Part 2)」をご参照ください。ステートフルルールグループの種類についても、開発者ガイドの Rule groups の箇所から詳細を確認することができます。
ステートフルルールのアクション設定として、標準ステートフルルールや Suricata 互換 IPS ルールでは、パス、ドロップ、アラート、拒否の 4 つからアクションを指定することができます。ここで、ドロップと拒否のルールにマッチした通信はアラートログに "blocked" と記録されますが、パスのルールにマッチした通信はアラートログには記録されません。そこで、許可された通信もログに記録する際には、こちらの例のようにパスのルールの前にアラートのルールを記載します。アラートのルールにマッチした通信は、アラートログに "allowed" と記録されますが、ファイアウォールはその後のルール評価を継続するため、通信を許可するためにはパスのルールも必要になります。
クリックすると拡大します
なお、対象の通信をブロックするアクションにはブロックと拒否の 2 つがありますが、その違いとしては、ブロックは対象のパケットを破棄するのみであるのに対して、拒否を設定した場合は対象のパケットを破棄したあと送信元に TCP リセットを送信します。もし遅延の影響を受けやすいアプリケーションがある場合には、拒否のアクションを設定してファイアウォールから TCP リセットを返すことにより、タイムアウトを待たずに次の処理を開始することができます。
また、Network Firewall では、ステートフルルールのデフォルトアクションとしてどのルールにもマッチしなかったパケットをアラートログに記録するように設定することが可能です。デフォルトアクションでドロップされたパケットのログを取得する場合は、こちらのようにファイアウォールポリシー設定の「ステートフルルール評価の順序とデフォルトのアクション」の箇所で「確立された接続のパケットをドロップ」を選択し、アラートアクションの箇所で「確立済み」にチェックを入れます。
ドロップアクションやアラートアクションの設定では、「すべてをドロップ」や「すべて」のログを記録する設定がありますが、アプリケーションレイヤーの検査をするルールがある場合、「すべてをドロップ」を選択していると、3 ウェイハンドシェイクの時点でドロップされてしまい、接続を確立するための通信を明示的に許可するルールを記述することが必要になります。そのため、ここでは「確立された接続のパケットをドロップ」を選択して、「確立済み」のパケットについてログを記録することが推奨されています。
クリックすると拡大します
なお、この場合にはアラートログの "signature" フィールドに "aws:alert_established action" と記録されるため、この情報をもとにデフォルトアクションでドロップされた通信かどうかを判別することができます。
Amazon CloudWatch Logs Insights を使用したログ分析
それでは、ここからは Amazon CloudWatch Logs Insights を使用して Network Firewall のログ分析を実施する方法を紹介していきます。CloudWatch Logs Insights は CloudWatch Logs のログデータに対して、簡単に検索やクエリ、分析を行うことができる Amazon CloudWatch の機能です。
CloudWatch Logs Insights を使用するためには、AWS マネジメントコンソールから CloudWatch の画面を開き、ログ > ログのインサイトをクリックします。ここでファイアウォールのログ保存先として設定しているロググループを選択し、クエリを実行してログを抽出します。
クエリ対象とするログの範囲については、画面右上に時間範囲を指定できる箇所があるため、ここから直近どのくらい前の時間を検索対象とするのか、あるいはいつからいつまでを検索対象とするのか具体的な日時を指定することができます。
クリックすると拡大します
ログ分析のユースケース
CloudWatch Logs Insights でクエリを実行する際には、所定の クエリ言語 を使用します。ここではいくつかのユースケースをもとに CloudWatch Logs Insights を使用して Network Firewall のログを分析する際のサンプルクエリを紹介します。
アラートログの可視化
この記事の前半でアラートログにどのようなフィールドがあるのかを説明しました。CloudWatch Logs Insights を使用して、ファイアウォールにおいてどのような通信が許可されていて、どのような通信がブロックされているのかを把握するためには、5-tuple (送信元 IP アドレス、送信元ポート番号、宛先 IP アドレス、宛先ポート番号、プロトコル) やファイアウォールのイベント情報を示すフィールドに着目して次のようなクエリを実行します。
fields @timestamp, event.event_type, event.alert.action, event.alert.signature, event.app_proto, event.src_ip, event.src_port, event.dest_ip, event.dest_port, event.tls.sni, event.http.hostnameこれによって、以下のように見やすい形でログを表示することができます。
クリックすると拡大します
ブロックされたドメインの分析
Network Firewall ではドメインリストを設定して、アウトバウンド通信のフィルタリングをすることができます。このようなユースケースでは、以下のようなクエリを実行することによって、ドメインリストによってブロックされた件数の多い FQDN の Top 10 を把握することができます。
この例では filter コマンドで event.alert.signature が "matching TLS denylisted FQDNs"、すなわち HTTPS のドメインリストで拒否された通信を抽出し、その結果を HTTPS 通信の宛先ごとに集計して降順で表示するようにしています。ドメインリストで拒否された HTTP 通信の宛先 Top 10 を表示したい場合には、event.alert.signature を "matching HTTP denylisted FQDNs" に変更し、event.tls.sni の箇所を event.http.hostname に置き換えます。
なお、Network Firewall のドメインリストでは、ドメイン名の検査をする際に、HTTPS の場合には TLS ハンドシェイク時の Server Name Indication (SNI) を参照し、HTTP の場合には HTTP リクエストの Host ヘッダの情報を参照していますので、ここでの出力は DNS クエリから取得できるドメイン名ではなく、HTTPS または HTTP 通信から取得できる宛先ホストの情報になります。
filter event.alert.signature = "matching TLS denylisted FQDNs"
| stats count(*) as numBlockedRequests by event.tls.sni
| sort numBlockedRequests desc
| limit 10
クリックすると拡大します
また、ブロックされた FQDN にアクセスをしている送信元 IP アドレスを調べたい場合には、以下のようなクエリを実行します。これによって、filter コマンドの event.tls.sni で指定した特定の FQDN に対してアクセスをしている送信元 IP アドレスの Top 10 を表示することができます。そして、その出力結果を分析することによって、拒否リストのドメインにアクセスをしているポリシー違反のユーザーやワークロードを特定したり、本来は許可されるべき通信であれば、この結果をもとに設定変更を検討することができます。
なお、インターネット向けの通信において、NAT ゲートウェイを通過したトラフィックを Network Firewall が検査するような構成の場合には、送信元 IP アドレスがすべて NAT 変換された IP アドレスとなるため、送信元 IP アドレスの分析をする際には、NAT ゲートウェイを通過する前のトラフィックに対して検査できるよう Network Firewall の配置にも留意する必要があります。この場合は、NAT ゲートウェイが配置されているパブリックサブネットのルートテーブルにおいて、インターネットからの戻りトラフィックがファイアウォールエンドポイントにルーティングされるように設定することがポイントになります。VPC 内のサブネット間のトラフィックをファイアウォールのようなアプライアンスに転送するためにローカルルートのターゲットを変更する方法については、Amazon VPC ユーザーガイドの「ミドルボックスアプライアンスのルーティング」を参照してください。
filter event.alert.action = "blocked" and event.tls.sni = "www.example.com"
| stats count(*) as numBlockedRequests by event.src_ip
| sort numBlockedRequests desc
| limit 10
クリックすると拡大します
検知したシグネチャの分析
最後に、特定の脅威を検知するためのルールを設定したり、マネージドルールを使用するようなケースにおいて、Network Firewall が検知したシグネチャを確認する場合のサンプルクエリを紹介したいと思います。ここでは、Network Firewall のルールにおいて、ブロックではなくアラートを設定して不審な通信を監視したり、マネージドルールを適用する前にアラートモードに設定して、誤遮断の影響がないか確認するようなユースケースを想定しています。
サンプルクエリとしては、アラートのアクションが設定されているルールを対象とするため、以下のように event.alert.action が "allowed" でかつevent.alert.signature フィールドが存在するログを抽出し、ヒットしたシグネチャの件数を集計して降順にソートして表示するようにしています。
これによって、検知したシグネチャの Top 10 がわかりますので、セキュリティの調査をする場合にも、誤検知かどうかの調査をする場合にも件数が多いものから対応を進めていくことができます。
filter event.alert.action = "allowed" and not isempty(event.alert.signature)
| stats count(*) as numEvents by event.alert.signature
| sort numEvents desc
| limit 10
クリックすると拡大します
どのようなシグネチャが検知されているのか把握したあとは、その送信元を確認することも重要です。ある特定のシグネチャにヒットしている通信の送信元 IP アドレスの Top 10 を表示するには、以下のようなクエリを実行します。ここでは、filter コマンドにおいて event.alert.signature で特定のシグネチャ名を指定して、その出力結果に対して送信元 IP アドレスの件数を集計して降順に表示しています。
filter event.alert.action = "allowed" and event.alert.signature = "(signatureの文字列を入力)"
| stats count(*) as numEvents by event.src_ip
| sort numEvents desc
| limit 10さらに、検出されたイベントの詳細を確認するためには、以下のようなクエリを実行します。
ここでは、アラートログから対象のシグネチャにマッチしているログを抽出し、以下の画面例のように、そのログを展開することによって、検出されたイベントの詳細を確認することができます。Network Firewall を侵入検知の用途で使用している場合には、運用におけるイベント確認やチューニングが欠かせませんので、このようなクエリを駆使してログを分析していくことは非常に重要です。
fields @timestamp, event.event_type, event.alert.action, event.alert.signature, event.alert.metadata.signature_severity.0, event.app_proto, event.src_ip, event.src_port, event.dest_ip, event.dest_port, event.tls.sni, event.http.hostname
| filter event.alert.signature = "(signatureの文字列を入力)"
クリックすると拡大します
まとめ
この記事では、AWS Network Firewall のログ記録設定や留意点を説明し、CloudWatch Logs Insights のサンプルクエリをもとに Network Firewall のログ分析を実施する方法を紹介しました。
Network Firewall を運用する際には、ファイアウォールのログ分析を実施することによって、トラフィックパターンを把握したり、ネットワーク内の異常なアクティビティを可視化することができます。それをもとに、セキュリティポリシーの見直しや強化、脅威の検知やインシデントの迅速な調査を実施することによりセキュリティを向上させることができます。
日々の運用では、CloudWatch Logs Insights のクエリ結果をウィジェットとして CloudWatch ダッシュボード に追加しておき、ネットワーク内の異常なアクティビティにすぐに気付くことができる仕組みを整えておくと良いでしょう。この記事で紹介したサンプルクエリを使用したり、可視化したい内容に合わせたクエリのカスタマイズをぜひ試してみてください。
この記事が、今後 AWS Network Firewall の導入や運用を検討される方の参考になれば幸いです。
筆者プロフィール
飯島 卓也
アマゾン ウェブ サービス ジャパン合同会社
シニア スペシャリスト テクニカルアカウントマネージャー (セキュリティ)
ネットワークとセキュリティ製品のテクニカルサポート、セキュリティ製品の導入や運用に伴う技術コンサルティングの経験を経て、AWS に入社。現在は、エンタープライズサポートに加入しているお客様向けにセキュリティ関連の技術支援を行っています。
AWS を無料でお試しいただけます