Squidを自前運用する時代の終わり？ついにAWSからマネージドプロキシがプレビューになったので検証する

あれもこれもと書いていたらかなり長くなってしまいました…
要点だけ知りたい方は最後のまとめセクションを見ていただければと思います。

はじめに

VPCにおけるアウトバウンドトラフィック制御といえばAWS Network Firewallが真っ先に候補に上がりますが、1つ気がかりな点がありました…

そんな気がかりな点を解消してくれるかもしれないアップデートが2025年11月25日に発表されました。AWS Network Firewall Proxyのプレビュー公開です。
本記事では、従来のアウトバウンドフィルタリング手法との比較を行い、Network Firewall Proxyがどのような課題を解決するのかを検証します。

https://aws.amazon.com/about-aws/whats-new/2025/11/aws-network-firewall-proxy-preview/

対象読者

• VPCのアウトバウンドトラフィック制御を検討しているネットワーク/セキュリティ担当者

• 従来のNetwork FirewallのSNI/Hostヘッダスプーフィング問題を認識しており、解決策を探している方

• Squid等のセルフマネージドプロキシの運用負荷に課題を感じている方

この記事で得られること

• 従来手法の課題理解: SNI/Hostヘッダスプーフィングがなぜ成立するか、シーケンス図で理解できる

• 比較検討の材料: Network Firewall / DNS Firewall / Squid / Network Firewall Proxyの機能比較

• 実装イメージの把握: マネジメントコンソールのスクリーンショットと実際の検証ログから、Network Firewall Proxyの動作を具体的に理解できる

• 検証環境の構築手順: CloudFormationテンプレートとルールグループCSVで、すぐに試せる

従来のアウトバウンドフィルタリングの課題

SNIスプーフィングとは

AWS Network Firewallのドメインリストルールは、HTTPの場合はHostヘッダ、HTTPSの場合はTLSハンドシェイク時のSNI（Server Name Indication）を検査します。しかし、これらは通信の内容を検査しているのであって、実際の通信の宛先を検査しているわけではありません。

従来型Network Firewallの問題点

以下のシーケンス図は、従来型Network Firewallでの通信フローと、なぜSNIスプーフィングが成立するのかを示しています。

①のマルウェアは以下のようなコマンドを実行し、SNIを偽装して通信します。

# 許可ドメイン（aws.amazon.com）のSNIを偽装しながら
# 実際には攻撃者のIPアドレスに接続
curl --resolve aws.amazon.com:443:93.184.216.34 https://aws.amazon.com/

Network Firewallは「SNIに書かれたドメイン名」を検査するだけで、「実際の接続先IP」との整合性は検証しません。攻撃者はSNIを偽装しながら、任意のIPアドレスに接続できてしまいます。

この問題については、以下の記事で詳しく解説されています。

https://zenn.dev/osprey/articles/networkfirewall-is-not-for-domainbase-restriction

プロキシによる解決

そこで登場するのがプロキシです。
プロキシを介した通信では、クライアントはまずプロキシに対して「どこに接続したいか」を伝えます（HTTP CONNECTリクエスト）。その後、プロキシ自身がDNS解決を行い、宛先への接続を確立します。

プロキシがDNS解決を代行するため、クライアントがIPアドレスを直接指定してSNI/Hostヘッダを偽装する攻撃は成立しません。 ドメイン名と実際の接続先IPの整合性が保証されます。

AWSにおけるVPCアウトバウンドトラフィック制御手法の比較

個人的にVPCからのアウトバウンドトラフィックを検査する構成として以下あたりが比較検討の俎上に挙がることが多いです。

1. AWS Network Firewall： VPCトラフィックを検査するマネージドファイアウォール

2. Route 53 Resolver DNS Firewall： DNS層でのフィルタリング

3. Squid Proxy（セルフマネージド）： OSSプロキシのセルフホスティング

4. AWS Network Firewall Proxy（NEW）：AWSマネージドプロキシ

機能比較

観点	Network Firewall	DNS Firewall	Squid (EC2)	Network Firewall Proxy
SNIスプーフィング対策（※¹）	×	△	○	○
TLS検査/HTTPヘッダ検査（※²）	○	×	○	○
クライアント設定（※³）	不要	不要	必要	必要
DNSトンネリング対策（※⁴）	×	○	×	○
運用負荷	低	低	高	低

各項目の補足

（※¹）SNIスプーフィング対策

• Network Firewall: SNIを検査するが、実際の宛先IPとの整合性は検証しない

• DNS Firewall: DNS層のみで制御するため、IPアドレス直接指定は防げない

• Squid/Network Firewall Proxy: プロキシがDNS解決を代行するため、スプーフィング不可

（※²）TLS検査/HTTPヘッダ検査

HTTPS通信の中身（HTTPメソッド、ヘッダ、ボディ等）を検査するには、TLSを終端して復号する必要があります。どの選択肢もACM Private CA等での証明書プロビジョニングやクライアントへの信頼設定など、追加の構成が必要です。HTTP（平文）通信であれば、TLS検査なしでヘッダ検査が可能です。

（※³）クライアント設定とは
「クライアント設定」とは、アプリケーションやOS側でプロキシサーバーを経由するよう設定することを指します。

# 環境変数での設定例
export http_proxy="http://proxy.example.com:3128"
export https_proxy="http://proxy.example.com:3128"

# curlでの明示的な指定例
curl -x http://proxy.example.com:3128 https://target.com

Network FirewallやDNS Firewallは「透過型」で動作するため、クライアント側の設定変更は不要です。一方、Squid ProxyやNetwork Firewall Proxyは「明示型（Explicit）」プロキシとして動作するため、クライアント側でプロキシを経由するよう設定が必要になります。

クライアント設定のバイパス対策

「クライアントを乗っ取られてプロキシ設定を外されたら終わりでは？」という懸念が浮かんだ方向けに対策案を記載します。これに対しては、ネットワークレベルでプロキシ経由を強制することで対策していきます。これらの対策を講じておくことで、IAM権限を奪取されなければ外部と通信させないで済みます。

対策1: Security Groupでの強制

クライアントのSecurity Groupで、アウトバウンドをプロキシ（リスナーポート）のみに制限します。

# クライアント用Security Group
SecurityGroupEgress:
  - IpProtocol: tcp
    FromPort: 443
    ToPort: 443
    DestinationSecurityGroupId: !Ref ProxyEndpointSecurityGroup
    Description: Allow HTTPS outbound to proxy endpoint
  - IpProtocol: tcp
    FromPort: 1080
    ToPort: 1080
    DestinationSecurityGroupId: !Ref ProxyEndpointSecurityGroup
    Description: Allow HTTP outbound to proxy endpoint
  # 直接インターネットへのEgressを許可しない = プロキシ経由でしかインターネットに出られない

対策2: ルートテーブルでの強制

プライベートサブネットのルートテーブルからNAT Gatewayへのデフォルトルートを削除し、プロキシ経由のみでの通信を強制します。

# NAT Gatewayへの直接ルートを削除
# 0.0.0.0/0 → NAT Gateway を設定しない

# クライアントはVPC Endpointを経由しないとインターネットに出られない
# プロキシを通さない通信はそもそも不可能

これらの対策により、クライアントがプロキシ設定を外しても、ネットワーク構成上インターネットへ直接アクセスできなくなります。

（※⁴）DNSトンネリング対策

DNSトンネリングとは、DNSプロトコルを悪用してデータを外部に持ち出す手法です。ファイアウォールは通常DNS（UDP/53）を許可しているため、この経路を使った情報流出は検知が困難です。

なぜこの攻撃が成立するのか：

1. 攻撃者はevil.comドメインを所有し、その権威DNSサーバーを運用している

2. マルウェアは流出させたいデータをサブドメイン部分にエンコードして埋め込む

3. 社内DNSはevil.comのレコードを持っていないため、DNSの仕組み上、必ず攻撃者の権威DNSサーバーに問い合わせが到達する

4. 攻撃者は受信したクエリのサブドメイン部分をデコードするだけで機密データを入手できる

5. 応答のTXTレコード等に次の指令を埋め込めば、双方向通信も可能

対策：

• DNS Firewall：マネージドルールでDGA（Domain Generation Algorithm）や異常に長いサブドメインを検知

• Network Firewall Proxy：PreDNSフェーズで接続ドメインのホワイトリストを定義

AWS Network Firewall Proxyとは

前置きが長くなってしまいましたが、ここからは実際にAWS Network Firewall Proxyを構築して、検証を行いながら要素を解説していきます。

アーキテクチャ

Network Firewall ProxyはNAT Gatewayと統合され、VPC Endpoint（PrivateLink）経由でアクセスします。
クライアントはVPC内のVPCEに対して接続するにとどまるので、NATGWへのルーティングは不要です。

Network Firewall Proxy検証構成

AWS Network Firewall Proxyの仕組み

Network Firewall Proxyは、トラフィックを3つのフェーズで検査します。

Phase 1: PreDNS

クライアントからのCONNECTリクエストを受信後、DNS解決を行う前に検査します。

• ドメイン名の許可/拒否

• DNSトンネリングの検出・ブロック

• 悪意のあるドメインへのDNSクエリ自体を防止

Phase 2: PreRequest

DNS解決後、実際のHTTPリクエストを送信する前に検査します。

• HTTPメソッドの制限（GET/POSTのみ許可など）※

• URLパスのフィルタリング

• HTTPヘッダの検査

Phase 3: PostResponse

外部サーバーからのレスポンスを受信した後、クライアントに返す前に検査します。

• Content-Typeの検査

• Content-Lengthの制限

• 不正なレスポンスのブロック

※ TLS Intercept（TLS検査）

HTTPS通信に対する、HTTPメソッドの監査等はTLS Interceptを有効にする必要があります。
有効化することでプロキシがTLSセッションを終端し、暗号化されたトラフィックの内容を検査できます。

TLS Interceptの仕組み | Securing Egress Architectures with Network Firewall Proxy

主な制限事項（プレビュー時点）

項目	制限
利用可能リージョン	US East (Ohio) のみ
プロキシモード	Explicit（明示的）モードのみ
料金	プレビュー期間中は無料

検証環境の構築

Step 0: VPC基盤のデプロイ（CloudFormation）

まず、VPC、サブネット、NAT Gateway等の基盤リソースをCloudFormationでデプロイします。
LLMにさくっと作ってもらいました。便利。

CloudFormation テンプレート（vpc-base-infrastructure.yaml）

AWSTemplateFormatVersion: '2010-09-09'
Description: |
  VPC Infrastructure for AWS Network Firewall Proxy Testing
  This template creates the base networking resources required for testing
  Network Firewall Proxy in the US East (Ohio) region.

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
      - Label:
          default: Environment Configuration
        Parameters:
          - EnvironmentName
      - Label:
          default: Network Configuration
        Parameters:
          - VpcCidr
          - PublicSubnetCidr
          - PrivateSubnetCidr

Parameters:
  EnvironmentName:
    Type: String
    Default: nfproxy-test
    Description: Environment name prefix for resources
    AllowedPattern: ^[a-zA-Z0-9-]+$
    ConstraintDescription: Must contain only alphanumeric characters and hyphens

  VpcCidr:
    Type: String
    Default: 10.0.0.0/16
    Description: CIDR block for the VPC
    AllowedPattern: ^([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]{1,2}$

  PublicSubnetCidr:
    Type: String
    Default: 10.0.11.0/24
    Description: CIDR block for the public subnet
    AllowedPattern: ^([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]{1,2}$

  PrivateSubnetCidr:
    Type: String
    Default: 10.0.1.0/24
    Description: CIDR block for the private subnet
    AllowedPattern: ^([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]{1,2}$

Resources:
  #============================================================================
  # VPC
  #============================================================================
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VpcCidr
      EnableDnsHostnames: true
      EnableDnsSupport: true
      InstanceTenancy: default
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-vpc

  #============================================================================
  # Internet Gateway
  #============================================================================
  InternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-igw

  InternetGatewayAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      InternetGatewayId: !Ref InternetGateway
      VpcId: !Ref VPC

  #============================================================================
  # Subnets
  #============================================================================
  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      AvailabilityZone: !Select [0, !GetAZs '']
      CidrBlock: !Ref PublicSubnetCidr
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-public-subnet-az1
        - Key: Type
          Value: Public

  PrivateSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      AvailabilityZone: !Select [0, !GetAZs '']
      CidrBlock: !Ref PrivateSubnetCidr
      MapPublicIpOnLaunch: false
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-private-subnet-az1
        - Key: Type
          Value: Private

  #============================================================================
  # NAT Gateway
  #============================================================================
  NatGatewayEIP:
    Type: AWS::EC2::EIP
    DependsOn: InternetGatewayAttachment
    Properties:
      Domain: vpc
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-nat-eip

  NatGateway:
    Type: AWS::EC2::NatGateway
    Properties:
      AllocationId: !GetAtt NatGatewayEIP.AllocationId
      SubnetId: !Ref PublicSubnet
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-nat-gw

  #============================================================================
  # Route Tables
  #============================================================================
  # Public Route Table
  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-public-rt

  DefaultPublicRoute:
    Type: AWS::EC2::Route
    DependsOn: InternetGatewayAttachment
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  PublicSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref PublicRouteTable
      SubnetId: !Ref PublicSubnet

  # Private Route Table
  # Note: No default route to NAT Gateway - traffic must go through Network Firewall Proxy via VPC Endpoint
  PrivateRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-private-rt

  # NAT Gateway への直接ルートは設定しない
  # クライアントは VPC Endpoint 経由で Network Firewall Proxy にアクセスし、
  # Proxy が NAT Gateway 経由でインターネットに接続する

  PrivateSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref PrivateRouteTable
      SubnetId: !Ref PrivateSubnet

  #============================================================================
  # Security Groups
  #============================================================================
  # Security Group for VPC Endpoint (Network Firewall Proxy)
  ProxyEndpointSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub ${EnvironmentName}-proxy-endpoint-sg
      GroupDescription: Security group for Network Firewall Proxy VPC Endpoint
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: !Ref VpcCidr
          Description: Allow HTTPS proxy traffic from VPC
        - IpProtocol: tcp
          FromPort: 1080
          ToPort: 1080
          CidrIp: !Ref VpcCidr
          Description: Allow HTTP proxy traffic from VPC
      SecurityGroupEgress:
        - IpProtocol: -1
          CidrIp: 0.0.0.0/0
          Description: Allow all outbound traffic
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-proxy-endpoint-sg

  # Security Group for CloudShell / Test Instances
  TestClientSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub ${EnvironmentName}-test-client-sg
      GroupDescription: Security group for test clients (CloudShell, EC2)
      VpcId: !Ref VPC
      SecurityGroupEgress:
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          DestinationSecurityGroupId: !Ref ProxyEndpointSecurityGroup
          Description: Allow HTTPS outbound to proxy endpoint
        - IpProtocol: tcp
          FromPort: 1080
          ToPort: 1080
          DestinationSecurityGroupId: !Ref ProxyEndpointSecurityGroup
          Description: Allow HTTP outbound to proxy endpoint
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-test-client-sg

#============================================================================
# Outputs
#============================================================================
Outputs:
  VpcId:
    Description: VPC ID
    Value: !Ref VPC
    Export:
      Name: !Sub ${EnvironmentName}-VpcId

  VpcCidr:
    Description: VPC CIDR Block
    Value: !Ref VpcCidr
    Export:
      Name: !Sub ${EnvironmentName}-VpcCidr

  PublicSubnetId:
    Description: Public Subnet ID
    Value: !Ref PublicSubnet
    Export:
      Name: !Sub ${EnvironmentName}-PublicSubnetId

  PrivateSubnetId:
    Description: Private Subnet ID
    Value: !Ref PrivateSubnet
    Export:
      Name: !Sub ${EnvironmentName}-PrivateSubnetId

  NatGatewayId:
    Description: NAT Gateway ID - Use this when creating Network Firewall Proxy
    Value: !Ref NatGateway
    Export:
      Name: !Sub ${EnvironmentName}-NatGatewayId

  NatGatewayPublicIp:
    Description: NAT Gateway Public IP Address
    Value: !Ref NatGatewayEIP
    Export:
      Name: !Sub ${EnvironmentName}-NatGatewayPublicIp

  ProxyEndpointSecurityGroupId:
    Description: Security Group ID for Proxy VPC Endpoint
    Value: !Ref ProxyEndpointSecurityGroup
    Export:
      Name: !Sub ${EnvironmentName}-ProxyEndpointSecurityGroupId

  TestClientSecurityGroupId:
    Description: Security Group ID for Test Clients (use with VPC CloudShell)
    Value: !Ref TestClientSecurityGroup
    Export:
      Name: !Sub ${EnvironmentName}-TestClientSecurityGroupId

  AvailabilityZone:
    Description: Availability Zone used for subnets
    Value: !Select [0, !GetAZs '']
    Export:
      Name: !Sub ${EnvironmentName}-AvailabilityZone

  DeployCommand:
    Description: Command to deploy this stack
    Value: !Sub |
      aws cloudformation deploy \
        --template-file vpc-base-infrastructure.yaml \
        --stack-name ${EnvironmentName}-vpc \
        --region us-east-2

  NextSteps:
    Description: Next steps after deployment
    Value: |
      1. Create Proxy Rule Group in VPC Console
      2. Create Proxy Configuration
      3. Create Network Firewall Proxy and associate with NAT Gateway
      4. Create VPC Endpoint for the Proxy
      5. Launch VPC CloudShell in private subnet for testing

このテンプレートで作成されるリソースは以下のとおりです。

リソース	説明
VPC	10.0.0.0/16
Public Subnet	10.0.11.0/24（NAT Gateway配置用）
Private Subnet	10.0.1.0/24（クライアント配置用、NAT Gatewayへの直接ルートなし）
Internet Gateway	インターネット接続用
NAT Gateway	アウトバウンド通信用（Proxyがアタッチされる）
Security Groups	Proxy Endpoint用、テストクライアント用

Private SubnetにNAT Gatewayへのルートがない理由

先にも触れましたが、クライアントはVPC Endpoint経由でNetwork Firewall Proxyにアクセスし、ProxyがNAT Gateway経由でインターネットに接続します。Private SubnetにNAT Gatewayへの直接ルートを設定すると、プロキシをバイパスできてしまうため、意図的に設定していません。

Step 1: プロキシルールグループの作成

VPCコンソール → プロキシルールグループ → プロキシルールグループを作成 でルールグループを作成します。

マネコンでの構築の模様

プロキシルールグループを作成をクリック

名前やタグ等のメタデータを定義

許可するドメインをカンマ区切りで記載

ルールの全体像はこんな感じ

ルールはCSV形式でエクスポート可能です。
今回は以下のとおり、3つのフェーズに対応するルールグループを作成しました。

ルールグループCSVの構造

rulePriority,ruleHookType,ruleName,ruleAction,conditionKey,conditionOperator,conditionValue

フィールド	説明
rulePriority	ルールの優先度（0から開始、数値が小さいほど先に評価）
ruleHookType	検査フェーズ（PreDNS, PreREQUEST, PostRESPONSE）
ruleName	ルール名
ruleAction	アクション（ALLOW, DENY, ALERT）
conditionKey	条件キー
conditionOperator	条件演算子
conditionValue	条件値（複数の場合はダブルクォートでカンマ区切り）

ルールグループ内の各ルールは2行で構成されます。1行目でルールの基本情報（Priority, HookType, Name, Action）を定義し、2行目で条件を指定します。

１．PreDNS: 許可ドメインリスト

rulePriority,ruleHookType,ruleName,ruleAction,conditionKey,conditionOperator,conditionValue
0,PreDNS,allow-aws-domains,ALLOW,,,
,PreDNS,allow-aws-domains,ALLOW,request:DestinationDomain,StringEquals,".amazonaws.com,aws.amazon.com,httpbin.org"

２．PreREQUEST: POSTメソッドのブロック

rulePriority,ruleHookType,ruleName,ruleAction,conditionKey,conditionOperator,conditionValue
0,PreREQUEST,block-post-method,DENY,,,
,PreREQUEST,block-post-method,DENY,request:Http:Method,StringEquals,POST

POSTメソッドをブロックすることで、データのアップロード（情報流出）を防止できます。TLS検査なしの場合、HTTPメソッドの検査はHTTPトラフィックのみで有効です。

３．PostRESPONSE: サーバーエラー監視

rulePriority,ruleHookType,ruleName,ruleAction,conditionKey,conditionOperator,conditionValue
0,PostRESPONSE,alert-server-errors,ALERT,,,
,PostRESPONSE,alert-server-errors,ALERT,response:Http:StatusCode,NumericEquals,500

完全なルールグループCSV例

以下は、上記3つのルールを1つのルールグループにまとめた例です。

rulePriority,ruleHookType,ruleName,ruleAction,conditionKey,conditionOperator,conditionValue
0,PreDNS,allow-aws-domains,ALLOW,,,
,PreDNS,allow-aws-domains,ALLOW,request:DestinationDomain,StringEquals,".amazonaws.com,aws.amazon.com,httpbin.org"
0,PreREQUEST,block-post-method,DENY,,,
,PreREQUEST,block-post-method,DENY,request:Http:Method,StringEquals,POST
0,PostRESPONSE,alert-server-errors,ALERT,,,
,PostRESPONSE,alert-server-errors,ALERT,response:Http:StatusCode,NumericEquals,500

Step 2: プロキシ設定の作成

先ほど作成したルールグループは単体で動作せず、プロキシ設定としてデフォルトアクションと合わせることで制御の仕様が決定されます。

1. VPCコンソール → Proxy configurations → Create proxy configuration

2. Default actionsを設定:

• PreDNS default action: DENY（許可ルールにマッチしないドメインを拒否）

• PreRequest default action: ALLOW（POSTブロックルール以外は許可）

• PostResponse default action: ALLOW（すべて許可）

1. 作成したRule Groupを関連付け

2. （オプション）TLS Interceptを有効化する場合はCA証明書を設定

デフォルトアクションについて

各フェーズのデフォルトアクションは、どのルールにもマッチしなかった場合に適用されるアクションです。PreDNSをDENYに設定することで、明示的に許可したドメイン以外へのアクセスをブロックするホワイトリスト方式を実現できます。嬉しいですね。

マネコンでの構築の模様

VPCコンソールからプロキシ設定を開き、プロキシ設定を新規作成する

3フェーズそれぞれでデフォルトアクションを定義

プロキシ設定に割り当てるルールグループを設定

作成完了

Step 3: Proxyの作成

1. VPCコンソール → プロキシ→ プロキシを作成

2. 以下を設定：

• Proxy configuration: 作成したConfiguration

• NAT Gateway: CloudFormationで作成済みのNAT Gateway

VPC Endpointの自動作成

Proxyを作成すると、専用のVPC Endpointが自動的に作成されます。別途VPC Endpointを手動で作成する必要はありません。作成完了後、VPCコンソールのEndpoints画面でエンドポイントのDNS名を確認できます。

マネコンでの構築の模様

プロキシを作成

プロキシの先のNATGWやプロキシ設定、TLS インターセプトの設定等を行う

スクロールしてログ配信設定 フェーズごとにログを出力することができる

作成 プロビジョニングに結構時間がかかった 20minくらい？

プロビジョニングが完了するとVPCエンドポイントが生えてくる

自動作成されたVPCエンドポイントにはデフォルトのセキュリティグループがアタッチされているので適宜修正してください。

検証シナリオ

各フェーズのルールが正しく動作することを確認します。

事前準備: VPC CloudShellの起動

1. CloudShellコンソールを開く

2. VPC environment を選択

3. 作成したVPCとプライベートサブネットを指定

4. client用のSGを設定

5. プロキシ利用のためのクライアント設定

プロキシ利用のためのクライアント設定

# プロキシエンドポイントの設定
PROXY_ENDPOINT="<Proxy FQDN>"  # 例: 098082876b41f02c4.proxy.nfw.us-east-2.amazonaws.com

# プロキシ環境変数の設定（小文字で設定）
export http_proxy="http://${PROXY_ENDPOINT}:1080"
export https_proxy="https://${PROXY_ENDPOINT}:443"

シナリオ1: PreDNS - ドメインフィルタリング

PreDNSフェーズでドメイン名に基づいてアクセス制御が行われることを確認します。

以下のテストは、事前準備でhttp_proxy/https_proxy環境変数が正しく設定されていることを前提としています。

# テスト1-1: 許可ドメインへのアクセス
curl -I https://aws.amazon.com
# 期待結果: HTTP 200 または 301/302

# テスト1-2: 許可ドメイン（サブドメイン）へのアクセス
curl -I https://docs.aws.amazon.com
# 期待結果: HTTP 200

# テスト1-3: 拒否ドメインへのアクセス
curl -I https://google.com
# 期待結果: HTTP 403 または接続拒否

# テスト1-4: Hostヘッダ偽装試行
# プロキシはHostヘッダではなくCONNECT先ドメインでフィルタリングするため、偽装は無効
curl -I http://google.com -H "Host: aws.amazon.com"
# 期待結果: HTTP 403 Forbidden（CONNECT先のgoogle.comが許可リストにないため拒否）

シナリオ2: PreREQUEST - HTTPメソッド制限

PreREQUESTフェーズでHTTPメソッドに基づいてアクセス制御が行われることを確認します。

このシナリオでは、httpbin.orgがPreDNSの許可リストに追加されている必要があります。また、TLS検査なしの場合、HTTPメソッドの検査はHTTPトラフィックのみで有効です。

# テスト2-1: GETメソッド
curl -I http://httpbin.org/get
# 期待結果: HTTP 200

# テスト2-2: POSTメソッド
curl -X POST http://httpbin.org/post
# 期待結果: HTTP 403（PreREQUESTルールによりDENY）

POSTメソッドをブロックすることで、データのアップロード（情報流出）を防止できます。GETのみ許可する構成は、参照系のみを許可したいユースケースで有効です。

シナリオ3: PostRESPONSE - ステータスコード監視

PostRESPONSEフェーズでレスポンスのステータスコードを監視できることを確認します。

TLS検査なしの制限

TLS検査を有効にしない場合、PostRESPONSEでHTTPフィールド（ステータスコード等）を検査できるのは暗号化されていないHTTPトラフィックのみです。HTTPSトラフィックのレスポンスを検査するにはTLS検査を有効にする必要があります。

# テスト3-1: 正常レスポンス（200）- アラートなし
curl -I http://httpbin.org/status/200
# 期待結果: HTTP 200（CloudWatchにアラートなし）

# テスト3-2: クライアントエラー（404）- アラートなし（500以外）
curl -I http://httpbin.org/status/404
# 期待結果: HTTP 404（CloudWatchにアラートなし）

# テスト3-3: サーバーエラー（500）- アラート発生
curl -I http://httpbin.org/status/500
# 期待結果: HTTP 500（CloudWatchにアラート記録）

PostRESPONSEのALERTアクションは、レスポンスをブロックせずにログを記録します。異常検知やモニタリング用途に適しています。

検証結果

検証結果は以下のとおりです。
参考までにコマンドのログやCloudWatchLogsに流れるログを貼っておきます。

シナリオ1: PreDNS

想定通りの結果を得られました。

テスト	内容	結果
1-1	aws.amazon.com	Allow
1-2	docs.aws.amazon.com	Allow
1-3	google.com	Block
1-4	Hostヘッダ偽装	Block

コマンドログ

~ $ PROXY_ENDPOINT="098082876b41f02c4.proxy.nfw.us-east-2.amazonaws.com"
~ $ export http_proxy="http://${PROXY_ENDPOINT}:1080"
~ $ export https_proxy="https://${PROXY_ENDPOINT}:443"
~ $ 
~ $ 
~ $ curl -I https://aws.amazon.com
HTTP/1.1 200 Connection Established

HTTP/2 200 
content-type: text/html;charset=utf-8
date: Thu, 27 Nov 2025 11:21:39 GMT
x-content-type-options: nosniff
server: Server
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
strict-transport-security: max-age=47304000; includeSubDomains
x-amz-id-1: 346BB92B3A234F45B2A4
last-modified: Wed, 19 Nov 2025 18:39:07 GMT
vary: accept-encoding
set-cookie: aws-priv=eyJ2IjoxLCJldSI6MCwic3QiOjB9; Version=1; Comment="Anonymous cookie for privacy regulations"; Domain=.aws.amazon.com; Max-Age=31536000; Expires=Fri, 27 Nov 2026 11:21:39 GMT; Path=/; Secure
set-cookie: aws_lang=en; Domain=.amazon.com; Path=/
x-cache: Miss from cloudfront
via: 1.1 e3b7adb90a75b52117d9b6715b5221bc.cloudfront.net (CloudFront)
x-amz-cf-pop: CMH68-P3
x-amz-cf-id: gge7B084rNKnmIbgVpqeUGzIhdHX6Ho6iwRmv3W1Wg3VGc3HYXbAQA==

~ $ 
~ $ 
~ $ curl -I https://docs.aws.amazon.com
HTTP/1.1 200 Connection Established

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 430000
Connection: keep-alive
Date: Thu, 27 Nov 2025 11:21:50 GMT
Server: Server
Cache-Control: no-store, no-cache, must-revalidate
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=47304000; includeSubDomains
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff
Content-Security-Policy: upgrade-insecure-requests; script-src 'self' 'unsafe-inline' *.awsstatic.com *.cdn.uis.awsstatic.com *.cdn.console.awsstatic.com d2c.aws.amazon.com a0.awsstatic.com *.feedback.console.aws.dev; object-src 'none';
Last-Modified: Wed, 26 Nov 2025 18:31:52 GMT
Accept-Ranges: bytes
ETag: "Fl9R8fH12FEw+REvOgfcPkUFDQk="
Vary: Accept-Encoding
X-Cache: Hit from cloudfront
Via: 1.1 7f1a329755833afcafe212b7fd6a065e.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: CMH68-P5
X-Amz-Cf-Id: 6WlTBQeLLkTGxbdJ5_kd3_lF0ftPeis5OFqzbCLq0leDBHyAdvBaJQ==

~ $ 
~ $ 
~ $ curl -I https://google.com
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Thu, 27 Nov 2025 11:22:41 GMT
Content-Length: 10

curl: (56) CONNECT tunnel failed, response 403


~ $ ping google.com
PING google.com (142.250.190.14) 56(84) bytes of data.
^C
--- google.com ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1061ms

~ $ curl -I http://142.250.190.46 -H "Host: aws.amazon.com"
HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Thu, 27 Nov 2025 11:25:12 GMT
Content-Length: 12

~ $ 
~ $ 
~ $ curl -I http://google.com -H "Host: aws.amazon.com"
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Thu, 27 Nov 2025 11:26:07 GMT
Content-Length: 10

#1-3、#1-4いずれもdest_domainがgoogle.com.になっているため、final_rule_name": "defaultとなり、デフォルトの動作DENYによってブロックされました。 プロキシはCONNECT先のドメイン名（実際の接続先）を見てフィルタリングするため、Hostヘッダを偽装しても意味がありません。これがプロキシ型アーキテクチャの強みです。

# 1-1
{
    "event_timestamp": 1764242499,
    "proxy_name": "test-proxy",
    "client_src_ip": "10.0.1.180",
    "final_action": "allow",
    "src_vpc": "vpc-0cca4474e958d61f2",
    "dest_domain": "aws.amazon.com.",
    "http_method": "",
    "dest_ip": "3.160.22.128",
    "http_status_code": -1,
    "final_rule_name": "default",
    "final_rule_group_name": ""
}   
# 1-2
{
    "event_timestamp": 1764242510,
    "proxy_name": "test-proxy",
    "client_src_ip": "10.0.1.180",
    "final_action": "allow",
    "src_vpc": "vpc-0cca4474e958d61f2",
    "dest_domain": "docs.aws.amazon.com.",
    "http_method": "",
    "dest_ip": "18.238.25.77",
    "http_status_code": -1,
    "final_rule_name": "default",
    "final_rule_group_name": ""
} 
# 1-3
{
    "event_timestamp": 1764242561,
    "proxy_name": "test-proxy",
    "client_src_ip": "10.0.1.180",
    "final_action": "deny",
    "src_vpc": "vpc-0cca4474e958d61f2",
    "dest_domain": "google.com.",
    "http_method": "",
    "dest_ip": "<nil>",
    "http_status_code": -1,
    "final_rule_name": "default",
    "final_rule_group_name": ""
}
# 1-4
{
    "event_timestamp": 1764242767,
    "proxy_name": "test-proxy",
    "client_src_ip": "10.0.1.180",
    "final_action": "deny",
    "src_vpc": "vpc-0cca4474e958d61f2",
    "dest_domain": "google.com.",
    "http_method": "HEAD",
    "dest_ip": "<nil>",
    "http_status_code": -1,
    "final_rule_name": "default",
    "final_rule_group_name": ""
}

シナリオ2: PreREQUEST

テスト	内容	実際の結果
2-1	GETメソッド	Allow
2-2	POSTメソッド	Block

コマンドログ

コマンドログ

~ $ curl -I http://httpbin.org/get
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 254
Content-Type: application/json
Date: Thu, 27 Nov 2025 11:39:56 GMT
Server: gunicorn/19.9.0

~ $ 
~ $ 
~ $ 
~ $ 
~ $ curl -X POST -I http://httpbin.org/post
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Thu, 27 Nov 2025 11:40:02 GMT
Content-Length: 10

~ $ 

以下、2つ目のJSONでhttp_methodがPOSTのとき、final_rule_name": "block-postによってブロックされていることがわかります。

logs

2-1
{
    "event_timestamp": 1764243538,
    "proxy_name": "test-proxy",
    "client_src_ip": "10.0.1.180",
    "final_action": "allow",
    "src_vpc": "vpc-0cca4474e958d61f2",
    "dest_domain": "httpbin.org.",
    "http_method": "HEAD",
    "dest_ip": "3.232.74.21",
    "http_status_code": 200,
    "final_rule_name": "default",
    "final_rule_group_name": ""
}  
2-2
{
    "event_timestamp": 1764243579,
    "proxy_name": "test-proxy",
    "client_src_ip": "10.0.1.180",
    "final_action": "deny",
    "src_vpc": "vpc-0cca4474e958d61f2",
    "dest_domain": "httpbin.org.",
    "http_method": "POST",
    "dest_ip": "52.7.3.57",
    "http_status_code": -1,
    "final_rule_name": "block-post",
    "final_rule_group_name": "allow-trusted-domains"
}

シナリオ3: PostRESPONSE の結果

テスト	内容	実際の結果
3-1	HTTP 200	Allow
3-2	HTTP 404	Allow
3-3	HTTP 500	Allow（ALERT）

コマンドログ

コマンドログ

~ $ curl -I http://httpbin.org/status/200
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 0
Content-Type: text/html; charset=utf-8
Date: Thu, 27 Nov 2025 11:41:31 GMT
Server: gunicorn/19.9.0

~ $ 
~ $ 
~ $ curl -I http://httpbin.org/status/404
HTTP/1.1 404 Not Found
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 0
Content-Type: text/html; charset=utf-8
Date: Thu, 27 Nov 2025 11:41:42 GMT
Server: gunicorn/19.9.0

~ $ 
~ $ 
~ $ 
~ $ curl -I http://httpbin.org/status/500
HTTP/1.1 500 Internal Server Error
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 0
Content-Type: text/html; charset=utf-8
Date: Thu, 27 Nov 2025 11:41:52 GMT
Server: gunicorn/19.9.0

今回も想定通り、3-3のみALERTログが出力されました。
ログの構造や中身は全く一緒で、出力されるロググループが違うというような形です。
allow: /aws/vendedlogs/network-firewall/proxy/ALLOW_LOGS/test-proxy
alert: /aws/vendedlogs/network-firewall/proxy/ALERT_LOGS/test-proxy

logs

# 3-1
{
    "event_timestamp": 1764243691,
    "proxy_name": "test-proxy",
    "client_src_ip": "10.0.1.180",
    "final_action": "allow",
    "src_vpc": "vpc-0cca4474e958d61f2",
    "dest_domain": "httpbin.org.",
    "http_method": "HEAD",
    "dest_ip": "52.6.181.49",
    "http_status_code": 200,
    "final_rule_name": "default",
    "final_rule_group_name": ""
}  
# 3-2
{
    "event_timestamp": 1764243701,
    "proxy_name": "test-proxy",
    "client_src_ip": "10.0.1.180",
    "final_action": "allow",
    "src_vpc": "vpc-0cca4474e958d61f2",
    "dest_domain": "httpbin.org.",
    "http_method": "HEAD",
    "dest_ip": "52.6.181.49",
    "http_status_code": 404,
    "final_rule_name": "default",
    "final_rule_group_name": ""
}  
# 3-3 Allowログ
{
    "event_timestamp": 1764243712,
    "proxy_name": "test-proxy",
    "client_src_ip": "10.0.1.180",
    "final_action": "allow",
    "src_vpc": "vpc-0cca4474e958d61f2",
    "dest_domain": "httpbin.org.",
    "http_method": "HEAD",
    "dest_ip": "100.29.246.92",
    "http_status_code": 500,
    "final_rule_name": "default",
    "final_rule_group_name": ""
}

# 3-3 ALERTログ
{
    "event_timestamp": 1764243712,
    "proxy_name": "test-proxy",
    "client_src_ip": "10.0.1.180",
    "final_action": "allow",
    "src_vpc": "vpc-0cca4474e958d61f2",
    "dest_domain": "httpbin.org.",
    "http_method": "HEAD",
    "dest_ip": "100.29.246.92",
    "http_status_code": 500,
    "final_rule_name": "default",
    "final_rule_group_name": ""
}

まとめ

• AWS Network Firewall Proxyは明示型プロキシとして動作し、NAT Gatewayと統合されてVPC Endpoint経由でアクセスする

• 従来のNetwork Firewallでは防げなかったSNIスプーフィング攻撃に対応可能（プロキシがDNS解決を代行するため、クライアントによるIP直接指定が不可）

• 3フェーズ検査（PreDNS / PreRequest / PostResponse） で段階的にトラフィックを制御

  • PreDNS: DNS解決前にドメイン許可/拒否、DNSトンネリング検出

  • PreRequest: HTTPメソッド・URL・ヘッダ検査（TLS検査なしの場合はHTTPのみ）

  • PostResponse: ステータスコード・Content-Type検査（TLS検査なしの場合はHTTPのみ）

• TLS Intercept（TLS検査）を有効化するとHTTPS通信の内容も検査可能

• プレビュー時点の利用可能リージョンはUS East (Ohio) のみ

• プレビュー期間中は無料、GA後の料金体系は未発表

• クライアント側でhttp_proxy/https_proxy環境変数の設定が必要（明示型のプロキシ）

• Security Groupやルートテーブルでプロキシ経由を強制することで、設定バイパスを防止可能

さいごに

最後までお読みいただきありがとうございます。
興奮するアップデートだったので長々と書いてしまいました。
かなり使えそうな機能だと思うので早くGA&東京R対応が待ち遠しいです。ただし、料金体系が発表されていないのが少し怖いですね…

参考資料

• AWS Network Firewall Proxy Developer Guide

• Securing Egress Architectures with Network Firewall Proxy | AWS Blog

• AWS Network Firewall Pricing

• Amazon Route 53 Pricing

• Network FirewallでSNIスプーフィングに対応できない問題