AWS Network Firewallを用いてインターネットからのインバウンド通信を集約して検査する際の考慮点を考えてみた
インターネットからのインバウンド通信の検査を集約する場合、どのような構成があって、どのような注意点があるのかな
こんにちは、のんピ(@non____97)です。
皆さんはインターネットからのインバウンド通信の検査を集約する場合、どのような構成があって、どのような注意点があるのか気になったことはありますか? 私はあります。
Network FirewallをとTransit GatewayやCloud WANを用いてインターネットからのアウトバウンド通信を集約して検査するのはよくある構成なのかなと思います。
一方でインバウンド通信の場合はどうでしょうか。アウトバウンド通信の場合と比べると少ないと感じます。
なぜ少ないのか、どのような構成が取り得るのか考えてみます。
いきなりまとめ
- インターネットからのインバウンド通信をNetwork Firewallで検査する構成は2パターン
- パターン1: IGW → Network Firewall → ALB
- パターン2: IGW → ALB → Network Firewall
- インバウンド通信の集約検査でNetwork Firewallを採用する事例は少ない
- 主に下記の理由による
- 外部公開している通信の多くは暗号化されており、TLSインスペクションなしでは検査範囲が限定的
- TLSインスペクション用のAdvanced Inspection Endpoint有効化で月額固定料金が約2.7倍 (576.70 USD → 2,175.40 USD)
- AWSマネージドルールグループでインバウンド方向に動作するルールは全体の約4% (900件 / 22,888件)
- HTTP / HTTPSの脅威はAWS WAFやAWS Shield Advancedで代替できる
- ALBがTCP終端することでSYNフラッドやUDPリフレクションを吸収してくれる
- 集約のためにVPCやAWSアカウントの分離が必要で管理負荷が高い
- クロスアカウントでの動的IPアドレス追従にハードルがある
- 通信ログはVPC Flow Logs / ALBアクセスログ / WAFログで一部代替可能
- HOME_NETの定義が複雑になり検出漏れが発生しやすい
- CloudFront VPC OriginsやGlobal Acceleratorはバイパス経路になる
- 主に下記の理由による
- それでもNetwork Firewallでインバウンド通信を検査するモチベーションになるケース
- HTTP / HTTPS以外のTLSプロトコル (SMTPS / IMAPS / LDAPS等) を外部公開している
- NLBでTCP / UDPサービスを外部公開している
- 脅威シグネチャマネージドルールグループのインバウンドルールに魅力を感じる
- コンプライアンスや監査要件でネットワーク型のIDS/IPSが明示的に求められる
- どのような脅威に対処したいのか、既存対策でカバーできない範囲はどこか、コストに見合うかを評価した上で導入を検討しよう
構成の整理
取り得る構成は大きくは以下2パターンです。
- インターネットに面するリソースの前段にNetwork Firewallを配置
- インターネットに面するリソースの後段にNetwork Firewallを配置
それぞれについて以下説明します。
1. インターネットに面するリソースの前段にNetwork Firewallを配置
こちらは IGW → Network Firewall → ALB のようにインターネットに面するリソースの前段にNetwork Firewallを配置する方式です。
図示すると以下のとおりです。
Cloud WANの場合はTransit Gatewayを単純に置き換えるだけで特に変わりはありません。
AWS Blogsにも以下のように紹介されています。
抜粋 : AWS Network Firewallのデプロイモデル | Amazon Web Services ブログ
抜粋 : AWS Network Firewallのデプロイモデル | Amazon Web Services ブログ
抜粋 : インターネットからのイングレストラフィックフローのためのファイアウォールのデプロイ設計 | Amazon Web Services ブログ
通常、TLSで暗号化されている箇所の通信について確認をすることはできませんが、TLSインスペクションをすることによって暗号化された箇所の検査をすることも可能です。
2. インターネットに面するリソースの後段にNetwork Firewallを配置
こちらは IGW → ALB → Network Firewall → ターゲット のようにインターネットに面するリソースの前段にNetwork Firewallを配置する方式です。
図示すると以下のとおりです。
こちらもCloud WANの場合はTransit Gatewayを単純に置き換えるだけで特に変わりはありません。
AWS Blogsにも以下のように紹介されています。
抜粋 : AWS Network Firewallのデプロイモデル | Amazon Web Services ブログ
抜粋 : インターネットからのイングレストラフィックフローのためのファイアウォールのデプロイ設計 | Amazon Web Services ブログ
こちらはALBなどインターネットに面するリソースでTLSの終端をしてくれるのであれば、TLSインスペクションが不要です。
一方、Network Firewallで見える送信元IPアドレスがALBなどのインターネットに面するリソースのIPアドレスとなってしまいます。
構成のPros/Consの整理
構成のPros/Consについて整理をします。
結論から言うと私は 2. インターネットに面するリソースの後段にNetwork Firewallを配置 の方が好みです。
Pros/Consを整理すると以下のとおりです。
| 観点 | パターン1 (IGW → Network Firewall → ALB) | パターン2 (IGW → ALB → Network Firewall) |
|---|---|---|
| TLS / HTTPS 通信の検査 | TLSインスペクションなしでは SNI など平文部分しか見えない。HTTPS の中身を検査するならTLSインスペクションが必須 | ○ ALB が TLS を終端するため、TLSインスペクション不要で平文 HTTP を直接検査できる |
| クライアント IP の可視性 | ○ クライアントのIPアドレスをそのまま確認できる | Network Firewallから確認できるクライアントIPアドレスがALBのプライベートIPアドレスとなり、真のクライアントIPアドレスは X-Forwarded-For ヘッダ経由でしか確認できない |
| Network Firewall 処理量 | DDoS試行やスキャン試行時などの全インバウンド通信が Network Firewall を通り、評価するため、Network Firewallの処理量に対する課金が増加する | ○ ALB および AWS WAFでドロップした後のトラフィックのみが Network Firewall を通る |
| East-West / Egress 用 Network Firewall の流用 | 別で調達が必要 (他Network Firewallと明示的に分離させたいのであれば気になる要素ではない) | ○ 同一の Network Firewall を流用しやすい。ALB → ターゲット の経路と East-West / Egress 経路がどちらも TGW を介して同じ Inspection VPC を通るため、Firewall のエンドポイント時間料金を節約できる |
インターネットからのインバウンド通信をNetwork Firewallで検査することが少ない理由の考察
まず、インターネットからのインバウンド通信をNetwork Firewallで検査することが少ない理由の考察をしてみます。
理由は以下があると考えています。
- インターネットからのインバウンド通信は暗号化されていることが多く、検査をしても有意義な結果が得づらいため
- TLSインスペクションのコストが高いため
- インターネットからのインバウンド通信に対する有効なAWSマネージドルールグループが少ないため
- AWS WAFやAWS Shield Advancedなど他のサービスによって対策が十分とされることが多いため
- ALBがL3/L4のプロキシ層を担ってくれているため
- インターネットからのインバウンド通信を集約して検査する際に、インターネットに面するリソースとターゲットのリソースのVPCやAWSアカウントを分離することになり、管理負荷が高いため
- インターネットからのインバウンド通信を集約して検査する際に、インターネットに面するリソースとターゲットのリソースのAWSアカウントを分離する場合、クロスアカウントでの動的IPアドレス追従にハードルがあるため
- 通信ログの集約はVPC Flow LogsやALBのアクセスログ、WAFのログでも一部代替可能であるため
- ALBの後段で検査する場合、CIDR整理を適切に行わなければ送信元IPアドレスがHOME_NETに含まれてしまい、十分な検出ができないため
- CloudFrontのVPC OriginsやGlobal Acceleratorなどを用いる場合などバイパス経路があるため
1. インターネットからのインバウンド通信は暗号化されていることが多く、検査をしても有意義な結果が得づらいため
一番の理由は インターネットからのインバウンド通信は暗号化されていることが多く、検査をしても有意義な結果が得づらいため ではないでしょうか。
広く外部公開しているインターネットからのインバウンド通信は主にHTTPSなのではないでしょうか。SSHやRDP接続はセキュリティグループで送信元IPアドレスをしっかり絞っているでしょう。
そうなると、Network Firewallの役回りとしては送信元IPアドレスと送信先ポートとセキュリティグループやNACL以外の要素で検出、防御することとなります。
しかし、外部公開しているインターネットからのインバウンド通信がHTTPSのような暗号化されている通信の場合、暗号化されていない要素でしか検査をすることができません。
これではせっかくNetwork Firewallを導入してもセキュリティグループ以上の働きをさせることができません。
2. TLSインスペクションのコストが高いため
では、TLSインスペクションを有効化すれば良いじゃないかという話ですが、TLSインスペクションのコストが気になります。
Network Firewallの料金は以下のとおりです。
| リソースタイプ | 料金 |
|---|---|
| Network Firewall Endpoint | USD 0.395/時間 |
| Network Firewall セカンダリエンドポイント | USD 0.158/時間 |
| Network Firewall トラフィック処理 | USD 0.065/GB |
| Network Firewall Advanced Inspection Endpoint | USD 1.095/時間 |
| Network Firewall Advanced Inspection Traffic Processing | USD 0.00/GB |
| Network Firewall Advanced Threat Protection トラフィック処理 | USD 0.005/GB |
抜粋 : AWS Network Firewall の料金 – ネットワークセキュリティサービス – Amazon Web Services 東京リージョン
TLSインスペクションを行う場合は通常のNetwork Firewall Endpointの料金とは別に、Network Firewall Advanced Inspection Endpointの料金が発生します。
トラフィック処理料金を除いた月額の固定料金について、Network Firewall Advanced Inspection Endpointの有無を比較します。
| Network Firewall Advanced Inspection Endpoint有無 | 月額料金 |
|---|---|
| なし | 0.395 USD/h × 2AZ × 730 h = 576.70 USD |
| あり | 0.395 USD/h × 2AZ × 730 h + 1.095 USD/h × 2AZ × 730 h = 2,175.40 USD |
追加で2.7倍ほどの料金がかかるのはかなりのインパクトなのではないでしょうか。
3. インターネットからのインバウンド通信に対する有効なAWSマネージドルールグループが少ないため
仮に、TLSインスペクションを有効化してHTTPSやSMTPS、POP3SなどのTLSで暗号化されていたトラフィックを検査できるようになったとします。また、HTTPSなどであってもトラフィックの未暗号化部分から不審な通信を検出できないのかも検討したいとします。
先述のとおり、Network Firewallの役回りとしては送信元IPアドレスと送信先ポートとセキュリティグループやNACL以外の要素で検出、防御することとなります。
具体的にはIPやTCP、HTTPなどの各種ヘッダー、ペイロードの内容を見てトラフィックの取り扱いをコントロールする形です。
運用者が0から脅威とみなす通信を検出または防御するルールを定義することは非常に難易度が高いでしょう。基本的にAWSが提供しているマネージドルールグループを採用することになるでしょう。
しかし、2026/5/31時点でAWSから提供されているマネージドルールグループにおいて、インターネットからのインバウンド通信に対する有効なものは少ないと言えます。
Network Firewallで提供されているマネージドルールグループは以下3種類があります。
- アクティブ脅威防御
- ドメインとIPアドレス
- 脅威シグネチャ
1つ目のアクティブ脅威防御で検出する脅威カテゴリは以下のとおりです。
| Indicator group and description | Traffic direction | Indicator types |
|---|---|---|
| Command and control Infrastructure that malicious actors use to remotely control compromised systems. |
Egress | IPs, domains |
| Malware staging Infrastructure that facilitates the distribution of malware and attack tooling. |
Ingress/Egress | URLs |
| Sinkholes Previously abused infrastructure used for malicious purposes. |
Egress | Domains |
| Out-of-band application security testing A technique where injected payloads make an outbound connection to external infrastructure that validates the existence of a vulnerability. |
Egress | IPs, domains |
| Crypto-mining pool Infrastructure used by crypto-miners. |
Egress | IPs, domains |
抜粋 : Understanding active threat defense managed rule group indicators - AWS Network Firewall
このように基本的にはEgress = インターネットへのアウトバウンド通信の検査を主としていることが分かります。
2つ目のドメインとIPアドレスについてもblock requests to a class of domains..やblock requests to domains that are known for hosting malwareと、不審なドメインへのリクエストをブロックするルールグループです。
| Rule name | Description and label |
|---|---|
AbusedLegitMalwareDomainsStrictOrder,AbusedLegitMalwareDomainsActionOrder |
Rules that allow you to block requests to a class of domains, which are generally legitimate but are compromised and may host malware. This can help reduce the risk of receiving malware or viruses originating from these sources with poor reputation. |
MalwareDomainsStrictOrder,MalwareDomainsActionOrder |
Rules that allow you to block requests to domains that are known for hosting malware. This can help reduce the risk of receiving malware or viruses originating from these known sources. |
AbusedLegitBotNetCommandAndControlDomainsStrictOrder,AbusedLegitBotNetCommandAndControlDomainsActionOrder |
Rules that allow you to block requests to a class of domains, which are generally legitimate but are compromised and may host botnets. This can help reduce the risk of resources accessing botnets originating from these sources with poor reputation. |
BotNetCommandAndControlDomainsStrictOrder,BotNetCommandAndControlDomainsActionOrder |
Rules that allow you to block requests to domains that are known for hosting botnets. This can help reduce the risk of resources accessing botnets originating from these known sources. |
抜粋 : AWS domain and IP managed rule groups for AWS Network Firewall - AWS Network Firewall
3つ目の脅威シグネチャは2026/5/31時点ではルールグループ内のルール総数は22,888個でした。
通信の方向について整理するとルール数は以下のようになります。
| カテゴリ | 定義 | 該当件数 |
|---|---|---|
| A | $EXTERNAL_NET or any → $HOME_NET + flow:to_server (外部から内部へのリクエスト) |
764 |
| B | $EXTERNAL_NET or any → $HOME_NET + flow:established のみ |
25 |
| C | $EXTERNAL_NET or any → $HOME_NET + flow 指定なし |
67 |
| D | $EXTERNAL_NET or any → $HOME_NET + flow:to_client (外部から内部へのレスポンス) |
3,881 |
| E | <> (双方向) |
0 |
| F | any → any |
28 |
| G | $HOME_NET → $EXTERNAL_NET or any + flow:to_server (内部から外部へのリクエスト) |
14,964 |
| K | $HOME_NET → $EXTERNAL_NET or any + flow:to_client (インバウンドリクエストに対するレスポンス) |
23 |
| L | $HOME_NET → $EXTERNAL_NET or any + flow 指定なし / established (その他Egress系) |
3,045 |
| I | $EXTERNAL_NET → any + flow:to_server (外部発、宛先 wildcard、リクエスト) |
69 |
| J | $EXTERNAL_NET → any + flow:to_client (外部発、宛先 wildcard、レスポンス) |
3 |
| H | その他 ($HOME_NET → $HOME_NET 13件、$HOME_NET → other 4件、$EXTERNAL_NET → $EXTERNAL_NET 2件) |
19 |
| 合計 | 22,888 |
このうちインターネットからのインバウンド通信について検査するものが含まれるものはカテゴリAとB、C、F、I、Kです。
B、C、Fについては通信の方向性の指定がないのでメッセージからさらに分類をすると以下のようになります。
| カテゴリ | 合計 | インバウンド検知 | クライアント保護 | post-compromise | 横展開 | スキャン検知 | IoT |
|---|---|---|---|---|---|---|---|
B (flow:established のみ) |
25 | 8 | 17 | 0 | 0 | 0 | 0 |
C (flow 指定なし) |
67 | 29 | 7 | 21 | 0 | 4 | 6 |
F (any → any) |
28 | 7 | 0 | 5 | 14 | 0 | 2 |
| 合計 | 120 | 44 | 24 | 26 | 14 | 4 | 8 |
これらを整理するとインターネットからのインバウンド通信について検査するルールは900件になります。
適合するルールの割合としては全体の約4%ほどです。数としてはどうしても少ないのではないのではないでしょうか。
記事執筆時点のルールの情報は以下GitHubリポジトリにも保存しています。
AWS Marketplaceからサブスクライブできるマネージドルールグループについても、インターネットからのインバウンド通信に対応しているものはそこまで多くないのではと考えます。
パッと見たところだと、Network Scanners Protection for Network Firewall by ThreatSTOPぐらいのように見えました。
マネージドルールグループが少ない = Network Firewallで十分な検知ができないと言う訳ではないですが、インターネットからのインバウンド通信のためだけにNetwork Firewallを導入するのはトータルのコストパフォーマンスが悪いように思えます。
4. AWS WAFやAWS Shield Advancedなど他のサービスによって対策が十分とされることが多いため
インターネットへ外部公開している通信がHTTPやHTTPSである場合を考えるとどうでしょうか。
これらに対してはAWS WAFやAWS Shield AdvancedがL7でコントロールをしてくれます。要するにHTTPヘッダーやリクエストボディで検査することが可能です。
加えてHTTPSであっても、NLBのようなTLSをパススルーするのではなく、TLSを一度終端してくれるALBやCloudFrontに関連付けるのであればTLSインスペクションのような追加料金は不要です。
先ほど紹介したとおり、AWSが提供しているマネージドルールグループでインターネットからのインバウンド通信に対して動作するルールの絶対数は少ないです。加えてコストも高いとなると、Network Firewallのみを導入してAWS WAFは導入しないというのは考えづらいのではないでしょうか。
このことからHTTPやHTTPSの場合はAWS WAFやAWS Shield Advancedなど他サービスによってによって対策が十分とされることが多いのではないでしょうか。
また、アンチマルウェア要件としてTrend MicroのTrendAI Vision One Endpoint Securityなどの製品をターゲット個々に導入する場合、ホスト型IPS/IDSの機能がこれら製品に含まれていることがあります。
ラテラルムーブメントなど任意のリソースへのアクセスを防ぐという観点であればネットワーク型のIPS/IDSも良いと思います。しかし、インターネットからのインバウンド通信であり、ターゲットが特定できるのであれば、そのターゲットで導入されているホスト型IPS/IDSで十分ではないかとも思います。
5. ALBがL3/L4のプロキシ層を担ってくれているため
Network FirewallはL3やL4に対しても動作してくれます。つまりは、AWS WAFでは対応できないレイヤーについてもカバーすることが可能です。
一方で、ALBは一度通信をTCP通信を終端してくれます。その恩恵により、ALBはSYNフラッドやUDPリフレクション攻撃などのL3やL4レイヤーの対処をしてくれています。
ウェブアプリケーションの場合、Application Load Balancer を使用してコンテンツに基づいてトラフィックをルーティングし、適切な形式のウェブリクエストのみを受け入れることができます。Application Load Balancer は、SYNフラッドDDoS攻撃やUDPリフレクション攻撃など、多くの一般的な攻撃をブロックし、攻撃からアプリケーションを保護します。Application Load Balancer は、これらのタイプの攻撃が検出されると、追加のトラフィックを吸収するように自動的にスケーリングします。インフラストラクチャレイヤー攻撃によるスケーリングアクティビティは、お客様にとって AWS 透過的であり、請求には影響しません。
そのため、ALBの後段でNetwork Firewallによる検査をするのであれば、ある程度ALBが不審なパケットを弾いてくれていると言えます。
6. インターネットからのインバウンド通信を集約して検査する際に、インターネットに面するリソースとターゲットのリソースのVPCやAWSアカウントを分離することになり、管理負荷が高いため
インターネットからのインバウンド通信を受けるシステムが多くある場合、各システムごとにNetwork Firewallを配置することになります。
それではNetwork Firewall自体のコストもそうですが、ルール管理などの運用維持コストも非常にかかります。
対応として、以下のようにインターネットからのインバウンド通信を集約して検査する方式が取られます。
VPCのリソースに紐づいているパブリックIPアドレスへのアクセスを他のVPCで受けることはできません。
そのため、集約の関係上、インターネットに面するリソースとターゲットのリソースのVPCやAWSアカウントを分離することになります。
結果として、Ingress VPCには各アプリケーションのALBやNLBが大量に作成されることになります。その結果、オペレーションミスやコスト配分、権限管理の難易度が増加してしまいます。
7. インターネットからのインバウンド通信を集約して検査する際に、インターネットに面するリソースとターゲットのリソースのAWSアカウントを分離する場合、クロスアカウントでの動的IPアドレス追従にハードルがあるため
現状、ターゲットグループでALBやNLBと別VPCのインスタンスIDやAuto Scaling Groupの指定および、ALBやNLBでクロスアカウントのターゲットグループを指定できません。
ロードバランサー VPC (同じリージョンまたは異なるリージョン) とピア接続されている VPC にインスタンスがある場合、そのインスタンスをインスタンス ID で登録することはできません。このようなインスタンスは IP アドレスで登録できます。
Application Load Balancer のターゲットグループ - Elastic Load Balancing
インスタンス ID でターゲットを登録する場合、インスタンスは Network Load Balancer と同じ VPC にある必要があります。ロードバランサー VPC (同じリージョンまたは異なるリージョン) とピア接続されている VPC にインスタンスがある場合、そのインスタンスをインスタンス ID で登録することはできません。このようなインスタンスは IP アドレスで登録できます。
Application Load Balancer を Network Load Balancer のターゲットとして関連付けるには、ロードバランサーが同じアカウント内の同じ VPC に存在する必要があります。
Network Load Balancer のターゲットとして Application Load Balancer を使用する - Elastic Load Balancing
そのため、ターゲットをAuto Scalingさせたり、ECS Fargateを採用したりと動的にリソースが変化する仕組みをとるのにハードルがあります。
全くできないという訳ではないのですが、追加でNLBを用意したり、サブネット共有をしたりする必要があります。構成は複雑になりますし、前者については追加コストも発生します。
抜粋 : Expose Amazon EKS pods through cross-account load balancer | Containers
8. 通信ログの集約はVPC Flow LogsやALBのアクセスログ、WAFのログでも一部代替可能であるため
もしかすると、インターネットからのインバウンド通信の集約の目的として、通信ログの集約もあるかもしれません。
しかし、VPC Glow LogsやALBのアクセスログ、AWS WAFのログでも一部代替できるのではないでしょうか。これらログはクロスアカウントでS3バケットに送信することが可能です。
となると、Network Firewallが出力するログでしか確認できない内容に価値があることになるのですが、さして違いはありません。
9. ALBの後段で検査する場合、CIDR整理を適切に行わなければ送信元IPアドレスがHOME_NETに含まれてしまい、十分な検出ができないため
ALBからターゲットにトラフィックをルーティングする際、そのトラフィックの送信元IPアドレスはALBのプライベートIPアドレスとなってしまいます。
そのため、ALBの後段にNetwork Firewallを配置する構成ではIPアドレスでの制御に注意する必要があります。
マネージドルールグループ内のルールではほぼ HOME_NET という保護対象となる自身のネットワークを定義した変数を使用しています。その結果、HOME_NET に ALBが属するIPアドレスレンジを含まれてしまうと、せっかくマネージドルールを定義してもほとんどがルール評価対象外となってしまいます。
Ingress VPCのCIDRがターゲットとなるVPCのCIDRと綺麗に分割できていない場合はHOME_NETの定義が複雑になります。
HOME_NETの定義はルールグループ単位ではなく、AWS Network Firewall単位です。そのため、上手くCIDRを切らなければ十分な検出ができない可能性があります。
10. CloudFrontのVPC OriginsやGlobal Acceleratorなどを用いる場合などバイパス経路があるため
仮にパターン1のインターネットに面するリソースの前段にNetwork Firewallを配置する形でインターネットからのインバウンド通信を集約して検査している場合、バイパスがあることも気になります。
具体的には、CloudFrontのVPC OriginsやGlobal Acceleratorを用いる場合です。この場合インターネットからのインバウンド通信はIGWを通りません。
- インターネットゲートウェイ – VPC オリジンリソースを持つ VPC にインターネットゲートウェイを追加する必要があります。インターネットゲートウェイは VPC がインターネットからトラフィックを受信できることを示すために必要です。インターネットゲートウェイは、サブネット内のオリジンへのトラフィックのルーティングには使用されないため、ルーティングポリシーを更新する必要はありません。
- 少なくとも 1 つの利用可能な IPv4 アドレスを持つプライベートサブネット – CloudFront は、プライベートオリジン CloudFront リソースの定義後に CloudFront で作成したサービスマネージド Elastic Network Interface (ENI) を使用してサブネットにルーティングします。ENI 作成プロセスを成功させるには、プライベートサブネットに少なくとも 1 つの利用可能な IPv4 アドレスが必要です。IPv4 アドレスはプライベートにすることができます。追加料金はかかりません。IPv6 専用サブネットはサポートされていません。
AWS Global Accelerator に Network Load Balancer、内部 Application Load Balancer、または Amazon EC2 インスタンスエンドポイントを追加すると、プライベートサブネットでターゲットにして、仮想プライベートクラウド (VPC) のエンドポイントとの間でインターネットトラフィックを直接送信できるようになります。ロードバランサーまたは EC2 インスタンスを含む VPC には、VPC がインターネットトラフィックを受け入れることを示す「インターネットゲートウェイ」がアタッチされている必要があります。ただし、ロードバランサーまたは EC2 インスタンスに公開 IP アドレスは必要ありません。また、サブネットに関連付けられたインターネットゲートウェイルートは必要ありません。
これは一般的なインターネットゲートウェイのユースケースとは異なり、VPC 内のインスタンスまたはロードバランサーにインターネットトラフィックを送信しるためには、パブリック IP アドレスとインターネットゲートウェイルートの両方が必要です。ターゲットの伸縮性のあるネットワークインターフェイスがパブリックサブネット (インターネットゲートウェイルートを持つサブネット) に存在する場合でも、インターネットトラフィックに Global Accelerator を使用すると、Global Accelerator は一般的なインターネットルートをオーバーライドし、Global Accelerator 経由で到着するすべての論理接続もインターネットゲートウェイではなく Global Accelerator 経由で返されます。
AWS Global Accelerator での安全な VPC 接続 - AWS Global Accelerator
インターネットからのインバウンド通信でNetwork FirewallへのルーティングをしているのはIGWのルートテーブルです。そのため、IGWを通らなければNetwork Firewallにルーティングをしてくれません。せっかく集約しようにも例外へのケアが必要となってしまいます。
インターネットからのインバウンド通信をNetwork Firewallで検査することによるモチベーション
では、インターネットからのインバウンド通信をNetwork Firewallで検査することによるモチベーションはなんでしょうか。
今までの内容を整理すると以下のようなものがあると考えます。
- HTTP/HTTPS以外のTLSプロトコルを外部公開している場合
- NLBでTCP/UDPサービスを外部公開している場合
- 脅威シグネチャマネージドルールグループのインバウンドルールに魅力を感じる場合
- コンプライアンスや監査要件で「ネットワーク型のIDS/IPS」が明示的に求められる場合
これらにマッチしない場合は積極的にインターネットからのインバウンド通信検査用途にNetwork Firewallを導入しなくとも良いかなと感じています。
参考までに各AWSのマネージドルールグループごとのカテゴリ別のルール数は以下のとおりです。
| グループ | 総数 | A | B | C | D | E | F | G | K | L | I | J | H |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Botnet | 3,484 | 3 | 0 | 20 | 1,631 | 0 | 2 | 1,194 | 1 | 630 | 1 | 1 | 1 |
| BotnetWeb | 2,420 | 0 | 0 | 0 | 96 | 0 | 0 | 2,320 | 1 | 1 | 0 | 0 | 2 |
| BotnetWindows | 3,289 | 39 | 0 | 0 | 485 | 0 | 0 | 2,755 | 3 | 2 | 3 | 1 | 1 |
| DoS | 24 | 9 | 0 | 6 | 1 | 0 | 1 | 1 | 0 | 5 | 0 | 0 | 1 |
| EmergingEvents | 56 | 0 | 0 | 0 | 11 | 0 | 16 | 18 | 0 | 11 | 0 | 0 | 0 |
| Exploits | 635 | 331 | 8 | 28 | 142 | 0 | 7 | 91 | 4 | 9 | 3 | 0 | 12 |
| FUP | 13 | 0 | 0 | 0 | 1 | 0 | 0 | 11 | 0 | 1 | 0 | 0 | 0 |
| IOC | 299 | 0 | 0 | 0 | 238 | 0 | 0 | 40 | 1 | 20 | 0 | 0 | 0 |
| MalwareCoinmining | 24 | 0 | 0 | 0 | 6 | 0 | 0 | 16 | 0 | 2 | 0 | 0 | 0 |
| MalwareMobile | 3,172 | 0 | 0 | 0 | 6 | 0 | 0 | 2,673 | 0 | 493 | 0 | 0 | 0 |
| Malware | 877 | 7 | 0 | 0 | 141 | 0 | 1 | 433 | 2 | 293 | 0 | 0 | 0 |
| MalwareWeb | 3,289 | 39 | 0 | 0 | 485 | 0 | 0 | 2,755 | 3 | 2 | 3 | 1 | 1 |
| Phishing | 4,152 | 1 | 17 | 4 | 156 | 0 | 0 | 2,421 | 0 | 1,553 | 0 | 0 | 0 |
| Scanners | 67 | 1 | 0 | 5 | 0 | 0 | 0 | 1 | 0 | 1 | 59 | 0 | 0 |
| Suspect | 178 | 0 | 0 | 1 | 1 | 0 | 0 | 173 | 0 | 3 | 0 | 0 | 0 |
| WebAttacks | 909 | 334 | 0 | 3 | 481 | 0 | 1 | 62 | 8 | 19 | 0 | 0 | 1 |
| TOTAL | 22,888 | 764 | 25 | 67 | 3,881 | 0 | 28 | 14,964 | 23 | 3,045 | 69 | 3 | 19 |
さらにマネージドルールごとにインターネットからのインバウンド通信について動作するものは以下のようになります。
| ルールグループ | A | B (内インバウンド通信検知) | C (内インバウンド通信検知) | F (内インバウンド通信検知) | I | K | 寄与計 | 累積率 | グループ総ルール数 |
|---|---|---|---|---|---|---|---|---|---|
| Exploits | 331 | 8 | 21 | 4 | 3 | 4 | 371 | 43.4% | 635 |
| WebAttacks | 334 | 0 | 1 | 1 | 0 | 8 | 344 | 83.6% | 909 |
| Scanners | 1 | 0 | 2 | 0 | 59 | 0 | 62 | 90.8% | 67 |
| BotnetWindows (=MalwareWeb 同一) | 39 | 0 | 0 | 0 | 3 | 3 | 45 | 96.1% | 3,289 |
| DoS | 9 | 0 | 5 | 1 | 0 | 0 | 15 | 97.9% | 24 |
| Malware | 7 | 0 | 0 | 1 | 0 | 2 | 10 | 99.1% | 877 |
| Botnet | 3 | 0 | 0 | 0 | 1 | 1 | 5 | 99.6% | 3,484 |
| BotnetWeb | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 99.8% | 2,420 |
| IOC | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 99.9% | 299 |
| Phishing | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 100.0% | 4,152 |
インターネットからのインバウンド通信に対してNetwork Firewallで検査する場合はこれらを元にマネージドルールグループを選定すると良いでしょう。
どのような脅威に対して対処したいのかや、既存の対策でカバーできていない範囲はどこなのか、導入やランニングコストに見合うのかを評価した上で導入しよう
AWS Network Firewallを用いてインターネットからのインバウンド通信を集約して検査する際の考慮点を考えてみました。
どのような脅威に対して対処したいのかや、既存の対策でカバーできていない範囲はどこなのか、導入やランニングコストに見合うのかを評価した上で導入しましょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
