投稿日

Virtual Private Gateway Type-F2とAWS Network Firewallでファイアウォール機能を作る

こんにちは、ソリューションアーキテクトのtaketoです。

日本人スポーツ選手の海外での活躍ニュースが多いですね。アメリカで活躍する野球選手 大谷翔平選手は歴史的54本塁打、59盗塁を達成。バスケットボールでは、日本代表の河村勇輝選手が同じくアメリカ NBAに挑戦中。なんだかいいですね、私も頑張ろうと思います。

さて本日は、先日リリースしたVirtual Private Gateway(以降、VPG)Type-F2を使ったセキュリティ対策例をご紹介したいと思います。

企業ネットワークでは、外部への通信を必要最低限にするセキュリティ対策を取ることがあります。以前 SA daiより「セキュリティを高める、SORACOM IoT SIMの通信先フィルタリングパターンのご紹介」を公開させていただきました。

今回は、そこでも話題に上がっていた「ドメインフィルタリング」などをAWS Network Firewallを使って実現する方法をご紹介したいと思います。

早速いってみましょう！

概要

検証概要

今回の検証で実現することとハイレベルなアーキテクチャをみていきましょう。

実現する機能としては、デバイスから特定のドメインに対してHTTP/HTTPSでのアクセスのみ許可し、それ以外は全てブロックする仕組みを構築していきます。

まずは、SORACOMのVPG Type-F2を利用します。Type-F2では従来のVPG Type-Fなどでできなかったデバイスからのパケットについてルーティング設定が可能になっています。詳細は、「VPG ルーティングテーブルを利用する」をご覧いただければと思いますが、デフォルトルート「0.0.0.0/0」をお客様のVPC宛にルーティングすることが可能になっています。これは非常に柔軟で様々なネットワーク構成が可能になりますが、一方でセキュリティが高いお客様などではこのケースでトラフィックをコントロールする必要性が出てきました。

FirewallのサービスとしてはAWS Network Firewallを利用します。

そして、インターネットの通信は通常VPGのインターネットゲートウェイを経由して通信いたしますが、今回はその通信をFirewall経由とするためインターネットゲートウェイはお客様VPCのものを利用します。

AWS Network Firewallとは

AWS Network Firewallは、Amazon Web Services（AWS）が提供するマネージド型のネットワークファイアウォールサービスです。このサービスは、通常VPC（Virtual Private Cloud）内のトラフィックを保護し、制御するために使われることが多いのですが、今回はSORACOMのIoTデバイスに対して適用してみます。

ルールグループと検証内容

AWS Network Firewallにはその制御する仕組みとしてルールグループを利用しますが、それぞれ2つタイプがあります。

  • ステートレスルールグループ：トラフィックの方向を考慮することなく、ステートレスルールエンジンが各パケットを個別に検査します。
  • ステートフルルールグループ：ステートフルルールエンジンは、個々のパケットだけではなくトラフィックフロー全体を評価します。トラフィックフローがドロップされた後は、そのフローに対して他のルールは適用されません。

お客様のご要望によって様々な構成が可能ですが、今回はHTTP/HTTPSを制御するためステートフルドメインリストルールグループを利用して特定のドメインのみ通信を許可する設定を実現してみましょう。補足ではございますが、HTTP/HTTPSなどTCP通信ではクライアントソケットにランダムなEphemeral Portを利用するため、:80や:443だけではなく戻りのルートもフィルタする必要があってステートフルルールを使います。

構築方法

アーキテクチャ

アーキテクチャ概要

今回の詳細なアーキテクチャを説明していきたいと思います。

ダイアグラムには、ルーティング情報まで記載しておりますが、AWS Network Firewall を利用する上でとても重要なポイントです。少し話が細かくなりますが、是非最後まで読んでみてください。

サブネット設計

今回は「プライベートサブネット」「ファイアウォールサブネット」「パブリックサブネット」という３つのサブネットを定義しています。注目いただきたいのが、「ファイアウォールサブネット」です。

AWS Network Firewallでは専用のサブネットを一つ作成する必要があります。特にサーバーなどは必要ありませんが、サービス自体をこのサブネットにホストすることとなります。

NAT Gatewayの利用

今回IoTデバイスのインターネット通信をAWS VPC経由でインターネット通信させる仕様にします。公式ドキュメント「Enable VPC internet access using internet gateways」に「resources on the internet can initiate a connection to resources in your subnet using the public IPv4 address or IPv6 address.」と記載がある通り、AWS Internet Gatewayの利用において、その送信元IPアドレスはVPCのアドレスレンジである必要があります。

しかし、VPG Type-F2を経由したIoTデバイスの通信において、その送信元IPアドレスはデバイスのIPアドレスレンジとなり、これはお客様VPCのIPアドレスレンジではありません。そのため、そのままお客様VPCのインターネットゲートウェイを経由しようとするとこれは拒否されます。

そこで登場するのが NAT Gatewayです。このサービスは送信元IPに関わらず、インターネットへ通信することができますので、今回のアーキテクチャで利用しています。

AWS Network Firewallとルーティング

さて、ここでAWS Network Firewallを適用するためのルーティングを詳しく解説します。

ここでのポイントは行きのパケットも戻りのパケットも両方AWS Network Firewallを経由させるという点です。非対称ルーティング（行きと帰りが異なる経路になること）でどちらかが抜け落ちるようなルーティングをしてしまうと期待値の通り動作しません。ここはよく陥りやすいポイントですので注意が必要ですので、気をつけてくださいね。

上のアーキテクチャ図に記載のルーティングテーブルの宛先「0.0.0.0/0」の経路を辿って頂ければと思いますが、デバイスからインターネットへの通信について、その経路は「デバイス」→　「VPG Type-F2」→　「Transit Gateway」→ 「プライベートサブネット」→　（AWS Network Firewall Endpoint）→「ファイアウォールサブネット」→「NATゲートウェイ」となります。

次に、戻りのインターネットからデバイスへの通信について、アーキテクチャ図のデバイス宛「10.128.0.0/9」の経路をたどってください。その経路は「パブリックサブネット（インターネットゲートウェイ）」→（AWS Network Firewall Endpoint）→　「ファイアウォールサブネット」→「Transit Gateway」→　「VPG Type-F2」　→　「デバイス」となります。

注意いただきたいのが、戻りのパケット経路です。ここがパブリックサブネット経由でAWS Network Firewall Endpointを経由させる必要がある点にご注意ください。これが設定されていない場合、非対称ルーティングとなり戻りのパケットがAWS Network Firewallを経由しないため制御ができません。

AWS Network Firewallのポリシーとグループ設定

それではAWS  Network Firewallについてみていきましょう。

Firewallの設定方法は色々な方法がありますのであくまでも一例としてみてください。みなさまの要件に合わせて「AWS Network Firewall のドキュメント」を確認して設定してください。

本検証では、HTTP/HTTPSに対して特定のドメインについてのみ許可する設定をいたします。このドメインの制御はステートフルドメインリストグループという設定で実施します。

Firewall設定のステートレスデフォルトアクションでは、以下のように設定することで全てのパケットに対してステートフルルールグループを適用する設定とします。

  • 完全なパケットに対するアクション：ステートフルルールグループに転送
  • フラグメントされたパケットのアクション：ステートフルルールグループに転送

次にステートフルルール評価の順序とデフォルトのアクション設定です。ここでは、複数のルールを定義した際は、優先度の数値が低いものから順に適用されます。。さらに全てのルールに該当しない場合はそのパケットをドロップする設定とします。

これにより、指定したアクセス許可するドメイン以外の通信は全てドロップされる状態となります。

  • ルールの順序：厳格な順序
  • デフォルトのアクション：確立された接続のパケットをドロップ

それでは最後にステートフルドメインリストルールグループの詳細です。ここでは通信を許可するドメインを登録します。許可するドメインはサンプルですのでお客様の環境に合わせて設定してください。

  • ドメイン：「soracom.jp」「google.com」（サブドメインも許可）
  • 検査するトラフィックとアクション：HTTP/HTTPS を許可
  • 送信元IP：10.128.0.0/9（デバイスのサブネット）

さてこれで設定が全て完了しました。

検証

早速テストをしてみましょう。

まずは許可されたドメインに対してHTTPで通信してみると、ご覧の通り全て通信できていますね。

pi@raspberrypi:~ $ curl -v -m 5 soracom.jp
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>CloudFront</center>
</body>
</html>
* Connection #0 to host soracom.jp left intact
pi@raspberrypi:~ $ curl -v -m 5 google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
* Connection #0 to host google.com left intact

次にサブドメインにアクセスしても、通信が許可されています。

pi@raspberrypi:~ $ curl -v -m 5 blog.soracom.jp
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>CloudFront</center>
</body>
</html>
* Connection #0 to host blog.soracom.jp left intact

最後に許可されていないドメイン 「soracom.io」にアクセスすると、期待通りタイムアウトします。これはAWS Network Firewallでパケットがドロップされるため、クライアントからはタイムアウトする挙動となります。

pi@raspberrypi:~ $ curl -v -m 5 soracom.io
*   Trying 3.82.81.201:80...
* Connected to soracom.io (3.82.81.201) port 80 (#0)
> GET / HTTP/1.1
> Host: soracom.io
> User-Agent: curl/7.88.1
> Accept: */*
>
* Operation timed out after 5000 milliseconds with 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 5000 milliseconds with 0 bytes received

おわりに

いかがでしたでしょうか？高度なFirewallが構築できましたね。今回はHTTP/HTTPSの制御をしましたが、ルールグループの設定によって様々なネットワーク制御が可能です。是非、お客様のユースケースにあった実装をして頂ければと思います。

― ソラコム松永 (taketo)