AWS Network FirewallのアラートログのソースIPが
NatGatewayのIPになる問題とその解決

投稿日: 2025/01/27

はじめに

NetworkFirewallとNatGatewayを組み合わせて、PrivateSubnetにあるサーバから特定のドメインへの接続を拒否し、拒否された場合には接続を行ったサーバを確認したいというケースがありました。しかし、実際にサーバから特定のドメインへの接続がNetworkFirewallによって拒否された際、アラートログのソースIPがNatGatewayになってしまうという問題が発生しました。そこで、本記事ではこの問題の解決法について解説します。

問題ケース

まず、NetworkFirewallとNatGatewayを組み合わせた構成を構築する際には、いくつかのサイト様を参考にしました。結果、サーバからNatGatewayへの接続、NatGatewayからNetworkFirewallへの接続、そしてNetworkFirewallからIGWへの接続という、以下の図に示すような構成が多く見られたため、この構成を作成しました。

構築が完了した後、無事にNetworkFirewallで拒否したドメインへの接続ができなくなり、想定通りの動作を確認しました。
そのため、次には不審な接続を行ったサーバを特定するために、アラートログを設定し、ソースIPからサーバを特定できるようにすることを考えました。

NetworkFirewallがドメインを拒否した際に、アラートログの機能を利用してどのサーバから通信が発生したのかを確認したところ、問題が発生しました。ログを見ると、ソースIPがNatGatewayのIPを示しており、どのサーバが通信を行ったのかがログから特定できませんでした。

-------[ログ]------
{
    "firewall_name": "kitagawa-firewall",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1737644104",
    "event": {
        "tx_id": 0,
        "app_proto": "tls",
        "src_ip": "10.0.13.92",
        "src_port": 58065,
        "event_type": "alert",
        "alert": {
            "severity": 1,
            "signature_id": 5,
            "rev": 1,
            "signature": "matching TLS denylisted FQDNs",
            "action": "blocked",
            "category": ""
        },
        "flow_id": 268007482899761,
        "dest_ip": "13.115.89.77",
        "proto": "TCP",
        "verdict": {
            "action": "drop"
        },
        "tls": {
            "sni": "www.ctc-g.co.jp",
            "version": "UNDETERMINED"
        },
        "dest_port": 443,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2025-01-23T14:55:04.080189+0000",
        "direction": "to_server"
    }
}
-------

解決方法

問題の原因は、NetworkFirewallがNatGatewayの前に配置されているため、サーバのIPが隠れてしまうことにあるようです。
そのための解決策としては、ルートテーブルを変更し、NetworkFirewallとNatGatewayの位置を逆に配置しました。
この変更に合わせて、IGWのIngressRoutingを解除し、NatGatewayのルートテーブルに宛先を追加します。

構成の変更を行った後、改めて動作確認を行ったところ、ドメインの拒否は正常に動作していることを確認出来ました。
次に、アラートログを確認してみます。

-------[ログ]------
{
    "firewall_name": "kitagawa-firewall",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1737646160",
    "event": {
        "tx_id": 0,
        "app_proto": "tls",
        "src_ip": "10.0.136.108",
        "src_port": 56143,
        "event_type": "alert",
        "alert": {
            "severity": 1,
            "signature_id": 5,
            "rev": 1,
            "signature": "matching TLS denylisted FQDNs",
            "action": "blocked",
            "category": ""
        },
        "flow_id": 82353452728821,
        "dest_ip": "13.115.89.77",
        "proto": "TCP",
        "verdict": {
            "action": "drop"
        },
        "tls": {
            "sni": "www.ctc-g.co.jp",
            "version": "UNDETERMINED"
        },
        "dest_port": 443,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2025-01-23T15:29:20.809006+0000",
        "direction": "to_server"
    }
}
-----------

先ほどのアラートログとは異なり、新しいアラートログでは正しくサーバのIPが表示されていることが確認できました。
これで、アラートログの情報を元にサーバを特定することができるようになりました。

まとめ

複数のサイト様ではNetworkFirewallを前面に配置した構成が紹介されており、フィルタリングとしては問題なく動作します。
しかし、今回のようなケースを視野に入れた場合、望んだ挙動にならないことがあります。
NetworkFirewallを利用する際は検知後の運用手法やログの取り扱い方法なども事前に考慮に入れたうえで設計構築を進める事をおすすめします。
もしAWSをご利用するにあたりご支援が必要な場合は、ぜひ弊社までお声がけください。

CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。